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I.  INTRODUCTION 

A.  BACKGROUND 

1 . The  Matrix  Organization  and  Program  Manager 

Concept. 

Project  management  is  the  central  organizational 
device  for  integrating  the  effort  required  to  develop  weap- 
ons systems  within  the  Department  qf_the  Navy.  The  primary 
characteristic  of  project  management  is  organization  by 
purpose  and  output  in  contrast  to  organization  around  func- 
tions, skills  or  disciplines  as  found  elsewhere  in  govern- 
ment and  in  industry.  Both  types  of  organizations  are  used 
in  Navy  Weapon  Systems  Acquisition  and  are  essential  to 
effective  and  economical  weapon  systems  development  and 
procurement.  The  functional  organization  is  superior  for 
advancing  the  state  of  the  art.  It  brings  together  the 
skills,  equipment  and  physical  facilities  required  for 
effective  performance.  The  project  management  concept  of 
organization  by  purpose  is  necessary  for  the  coordination 
and  integration  of  the  output  of  the  functional  organization 
in  order  to  insure  that  desired  program  purposes  are  accom- 
plished. 

2 . Management  Control  and  Information. 

Management  control  over  all  aspects  of  the  project 
is  delegated  to  the  Program  Manager  in  the  program  charter 
issued  by  the  cognizant  authority  and  is  vital  to  the 
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efficient  and  effective  functioning  of  a Program  Office. 
Having  the  authority  for  program  control  and  actually  achiev- 
ing effective  program  control  is,  particularly  within  a 
matrix  configuration,  another  matter.  Since  he  does  not 
have  line  authority  over  individuals  outside  the  Program 
Office,  the  Program  Manager's  task  is  one  of  exercising 
tact,  diplomacy  and  leadership  in  enlisting  the  cooperation 
of  both  seniors  and  subordinates  in  the  functional  organiza- 
tions that  actually  provide  the  support  for  the  program. 

The  degree  of  management  control  and  its  effective- 
ness is  directly  proportional  to  the  information  flow  to  and 
from  the  program  office.  Information  exchanges  upward, 
downward  and  laterally  must  be  established  and  nurtured. 

The  outward  information  flow  provides  the  guidelines  to 
accomplish  the  goals  of  the  program  office.  In  order  for 
this  tool  to  be  effective,  however,  information  must  be  fed 
back  to  the  program  office.  This  is  the  information  used  in 
management  appraisal  - assessing  the  effectiveness  of  exist- 
ing policies,  developing  and  evaluating  policy  changes, 
measuring  progress,  replanning,  rescheduling  and  all  the 
other  activities  necessary  in  accomplishing  objectives  and 
utilizing  government  and  contractor  resources  to  the  fullest 
extent  possible.  The  existence  of  this  "closed-loop"  charac- 
teristic in  the  information  flow  is  essential  for  successful 
program  management. 
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An  effective  "directive  and  reporting"  system, 
while  an  important  aspect  of  communication,  will  not  suffice 
for  an  information  system  in  program  management.  The  pre- 
paration time  alone  for  such  documents  obviates  their  use  in 
real-time  program  management.  A successful  program  office 
will  utilize  a combination  of  communication  methods  - letter, 
message,  telephone,  telecopier,  film,  conferences,  etc. 
Building  an  information  network  and  maintaining  its  effec- 
tiveness is  essential  to  the  successful  accomplishment  of 
the  primary  tasks  of  the  Program  Manager. 

3 . Sidewinder  Program  Management, 
a.  Organizational  Relationships 

Project  management  in  the  Naval  Air  Systems 
Command  (NAVAIR)  cuts  across  the  functional  organization 
under  the  Chief  of  Naval  Material  (CNM)  and  serves  as  a 
single  point  of  contact  and  effort  to  get  the  job  done. 
Project  managers  operate  under  charters  issued  by  CNM  or  by 
the  Commander  of  a Systems  Command.  NAVAIR  has  cognizance 
for  the  Sidewinder  missile  and  the  Infrared  Missiles  Program 
Manager  (PMA-259),  is  chartered  by  and  reports  directly  to 
the  Commander  of  the  Naval  Air  Systems  Command.  The  project 
charter  prescribes  the  scope  of  authority,  responsibility 
and  operating  relationships  of  PMA-259. 

The  Sidewinder  Program  Office  at  the  Naval 
Weapons  Center  (SPO/NWC)  at  China  Lake,  is  also  organized 
around  a project  management  matrix  concept.  The  project 
management  approach  is  used  to  provide  an  integrated,  single 
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point-of-contact  at  the  Naval  Weapons  Center  (NWC)  and 
maintain  the  emphasis  on  output  required  to  bring  a new 
weapon  into  operational  service.  The  SPO/NWC  provides  this 
interface  and  point-of-contact  between  NWC  and  other  DoD 
and/or  civilian  activities.  The  SPO/NWC  is  also  the  inter- 
face for  the  program  to  the  functional  codes  within  NWC 
which  actually  provide  the  services  and  accomplish  the  tasks 
required. 

The  SPO/NWC  is  administratively  located  in 
the  Engineering  Design  Division  of  the  Engineering  Depart- 
ment. The  SPO/NWC  tasks  and  funds  continuing  efforts  in 
several  divisions/departments  throughout  NWC.  Other  branches 
are  intermittently  tasked  to  support  the  analysis,  design, 
testing,  and  evaluation  functions-  necessary  to  put  the 
Sidewinder  missile  system  into  Navy  and  Air  Force  arsenals, 
b.  Role  and  Responsibility  of  SPO/NWC 

NWC  is  ,ked  with  the  responsibility  for  the 
technical  support  of  the  Sidewinder  missile  (AIM-9)  systems 
by  NAVAIR.  This  technical  support  task  is  comprised  of 
production  support,  development,  testing,  and  Integrated 
Logistics  Support  (ILS)  functions.  In  order  to  accomplish 
these  fundamental  functions,  tremendous  coordination  is 
required  between  NWC  and  NAVAIR,  Participating  Field  Activi- 
ties (PFAs),  co-sponsoring  Air  Force  activities,  and  primary 
and  secondary  source  contractors  for  AIM- 9 hardware  and 
software.  In  addition,  the  coordination  of  tasks  distri- 
buted among  the  NWC  functional  codes  must  be  accomplished. 
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SPO/NWC  provides  the  coordination  required  in  both  these 
areas . 

Overall  responsibility  for  tasking  and  fund- 
ing commitments  are  received  by  the  SPO/NWC  in  the  form  of 
AIRTASK  and  Work  Unit  Assignment  documents  from  NAVAIR  and 
Project  Orders  from  other  Navy  and  Air  Force  field  activi- 
ties. The  SPO/NWC  release- to-work  documents  are  Task  Agree- 
ments to  the  NWC  supporting  codes.  Project  Orders  to  other 
field  activities  and  contracts  to  civilian  industry. 

c.  The  Management  Information  and  Control  Prob- 
lem Within  SPO/NWC 

The  myriad  of  technical,  operational,  finan- 
cial and  administrative  details  involved  in  managing  the 
AIM-9  program  at  NWC,  are  handled  by  the  twelve  individuals 
in  the  SPO/NWC,  and  many  others  throughout  the  NWC  support- 
ing codes.  These  individuals  each  maintain  personal  files 
and  records;  however,  no  single  file  or  set  of  files  aggre- 
gates or  integrates  the  information  contained  in  these 
files.  Much  of  the  information  flow  is  verbal,  or  in  in- 
formal notes  and  memoranda  from  many  different  sources  and 
on  many  diverse  subjects,  which  is  not  captured  in  any 
formal  file  for  use  by  the  Program  Manager.  The  present 
loss  of  information  through  inaccessibility  (travel,  leave, 
etc.)  of  key  individuals  and  lack  of  proper  documentation 
results  in  considerable  time  being  consumed  in  data  searches 
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and  duplication  of  effort.  The  combination  of  these  situa- 
tions results  in  a lack  of  overall  visibility  into  total 
organizational  workload  for  planning  purposes  and  insuffi- 
cient control  of  progress  in  accomplishment  of  assigned 
tasks . 

B.  THESIS  HYPOTHESIS  AND  OBJECTIVES 
1.  Hypothesis . 

The  hypothesis  of  this  thesis  is  that  the  Program 
Manager  concept  and  utilization  of  the  matrix  organization 
technique  for  program  management  accentuates  the  need  for  a 
comprehensive  and  timely  management  control  system  within 
the  context  of  a program  management  information  system 
(MIS) . In  particular,  the  SPO/NWC  Manager  has  a definite 
requirement  for  a comprehensive,  responsive  management 
information  and  control  system  (MICS)  to  enable  him  to 
properly  perform  the  multitude  of  tasks  required  of  his 
organization.  The  authors  believe  that  the  current  control 
system  employed  at  the  SPO/NWC  is  not  adequate  to  fulfill 
the  need.  It  requires  an  inordinate  amount  of  managerial 
time  to  monitor  task  completion  and  the  system  is  not  com- 
prehensive enough  to  insure  that  all  tasks  are  monitored. 

In  addition,  it  does  not  provide  adequate  visibility  to 
allow  for  proper  program  planning  and  allocation  of  re- 
sources. It  is  further  believed  that  an  improved  system 
would  be  less  time  consuming  and  provide  information  for 
successful  program  planning  and  control. 
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2.  Objectives 


The  objectives  of  this  thesis  are:  1)  to  identify 

and  discuss  the  criteria  and  considerations  appropriate  for 
a viable  MICS,  2)  to  examine  the  existing  SPO/NWC  environ- 
ment and  MICS  to  identify  roles,  responsibilities,  informa- 
tion flow  and  controls,  3)  to  stipulate  the  information  and 
control  requirements  deemed  necessary  by  the  authors  to 
insure  successful  SPO/NWC  control,  4)  to  evaluate  the  cur- 
rent MICS  and  ascertain  the  need  for  improvement,  and  5)  to 
recommend  a MICS  framework  for  subsequent  system  design  and 
implementation . 

C . METHODOLOGY 

1.  Process  and  Scope 

The  development  of  MISs  has  evolved  into  a process 
much  the  same  as  the  weapon  system  acquisition  process. 
Current  literature  calls  for  a project  manager  concept 
employing  "user-producer"  (management-designer)  dialog,  and 
delineates  a system  life  cycle  approach.  Although  the 
descriptions  of  this  system  life  cycle  range  in  the  litera- 
ture from  those  with  four  phases  to  one  model  with  twelve 
phases,  the  concepts  are  the  same.  The  system  passes 
through  various  stages  in  development  from  inception  to  full 
utilization. 

One  such  model  of  the  systems'  life  cycle  was 
presented  by  J.  T.  Rigo[l]  and  portrayed  an  eight-phase 
development.  The  eight  phases  are  depicted  in  Table  I-A. 
This  thesis  will  encompass  the  first  three  phases  in  the 
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PHASE 


EVENTS /TASKS 


Initiation 


Survey 


Statement  of  the  Problem 
Statement  of  Objectives 
Statement  of  Anticipated  Benefits 

Documentation  of  Current  Situation 


Requirements  Stipulation  of  User  Requirements 

-outputs 

Identification  of  Alternative 
Gross  Designs 

-inputs,  outputs,  processing 


Preliminary  Design  Selection  of  a Gross  Design 

Alternative 

Preparation  of  Functional 
Specifications 

Cost/Benefit  Analysis 

Detail  Design  Preparation  of  System  and  Program- 

ming Specifications 

Plans  for  Training,  Forms  and 
Manual  Preparation 


Development  Programs  Written 

Hardware  Procured 

Forms  and  Procedures  Designed 


Implementation 


Evaluation 


System  Tested  in  Parallel  with 
Existing  System 

Operational  Acceptance 

Cost  and  Performance  Evaluated 

Modifications  Implemented  as 
Required 


INFORMATION  SYSTEM  DEVELOPMENT  STRUCTURE [1] 

TABLE  I -A 
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process  and  the  selection  of  a gross  design  alternative.  It 
is  felt  that  this  is  the  extent  of  the  effort  which  can  be 
accomplished  within  the  time  constraints  imposed  and  the 
level  of  technical  expertise  of  the  authors. 

Another  limitation  of  the  scope  of  the  thesis  is 
in  the  area  of  the  SPO/NWC  functions.  As  indicated  pre- 
viously, the  SPO/NWC  has  the  responsibility  for  all  techni- 
cal support  of  the  Sidewinder  missile  system.  While  the 
problems  and  objectives  described  earlier  are  applicable  to 
the  total  SPO/NWC  operation,  this  thesis  will  concentrate 
only  on  the  AIM-9L  Production  Support  functions  in  its 
analysis.  This  limitation  is  self-imposed  in  order  to 
reduce  the  research  effort  to  a level  commensurate  with  time 
restrictions.  It  is  felt  that  this  limitation  is  not  detri- 
mental to  the  overall  effort  in  that  AIM-9L  Production 
Support  represents  about  forty  percent  of  the  SPO/NWC  work- 
load and  is  representative  of  the  remaining  efforts  in  terms 
of  management  planning  and  control. 

2 . Personal  Contact 

Information  for  this  thesis  has  been  gathered 
largely  through  personal  contact  with  key  members  of  the 
SPO/NWC.  One  of  the  authors  is  the  Program  Manager  of  the 
SPO/NWC  and  the  other  author  made  a total  of  five  visits  to 
NWC  over  a period  of  nearly  six  months.  During  these  visits, 
management  information  and  control  aspects  of  the  program 
were  discussed  in  depth,  and  pertinent  technical  features 
were  reviewed  with  key  personnel. 
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3.  Review  of  Current  Literature 


Basic  research  was  conducted  in  order  to  gain 
knowledge  and  appreciation  in  the  areas  of  management  con- 
trol and  planning  and  management  information  systems.  This 
was  accomplished  by  reviewing  current  periodicals,  books, 
and  reports.  The  more  pertinent  of  the  material  reviewed  is 
listed  in  the  Bibliography. 

4 . Analysis 

Decision  level  analysis  and  information  flow 
analysis  were  both  employed  in  the  evaluation  of  the  facts 
for  this  thesis.  Techniques  used  in  these  analyses  included 
organizational  charting  and  information  and  systems  flow 
charting.  Input  and  output  volume  and  frequency  data  wt.  5 
collected  by  total  item  count  over  a designated  period. 

D.  THESIS  ORGANIZATION 

This  thesis  is  organized  to  coincide  with  and  achieve 
the  thesis  objectives  previously  outlined.  Chapter  II  is  a 
survey  of  the  literature  search  in  the  areas  of  planning  and 
control  and  MIS,  and  includes  the  design  considerations  and 
criteria  currently  held  by  various  authors  as  appropriate  to 
the  MICS  development  process.  It  presents  two  conceptual 
frameworks  within  which  to  view  a MICS  and  the  implications 
of  those  frameworks  upon  the  MICS  in  the  areas  of  informa- 
tion requirements,  system  characteristics,  and  the  system 
design  process.  The  chapter  concludes  with  a discussion  of 
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criteria  for  selection  of  a MICS  type  for  a specific  appli- 
cation. Readers  familiar  with  MICS  concepts  and  capabili- 
ties need  not  read  this  chapter. 

Chapter  III  examines  the  existing  SPO/NWC  environment 
and  MICS.  It  explores  the  organizational  relationships  of 
those  activities  which  interact  with  the  SPO/NWC  in  the 
Sidewinder  Program,  and  the  roles,  responsibilities,  and 
information  flows  associated  with  these  relationships.  Also 
delineated  in  this  chapter  are  the  processes  of  task  assign- 
ment within  these  relationships  and  the  current  SPO/NWC 
systems  utilized  for  planning  and  control  purposes.  This 
chapter  represents  the  Survey  Phase  of  the  Rigo  MICS  develop- 
ment model  previously  outlined. 

The  establishment  of  the  information  and  control  require- 
ments necessary  to  ensure  successful  SPO/NWC  operation  are 
outlined  in  Chapter  IV.  First,  general  goals  and  objectives 
for  a viable  SPO/NWC  MICS  are  presented  and  the  current 
information  and  control  systems  are  evaluated  in  light  of 
those  goals  and  objectives.  Secondly,  a conceptual  model 
for  an  appropriate  SPO/NWC  MICS  is  presented.  Thirdly,  the 
proposed  conceptual  model  is  further  defined  in  terms  of 
more  specific  system  outputs,  data  processing  required,  and 
data  inputs  required.  Chapter  IV  is  an  application  of  the 
Rigo  Requirements  Phase  to  SPO/NWC. 

Finally,  Chapter  V presents  a brief  summary  of  the 
thesis  to  that  point  and  outlines  the  conclusions  and  recom- 
mendations of  the  authors. 
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II.  MANAGEMENT  INFORMATION  AND  CONTROL  SYSTEMS 


DESIGN  CONSIDERATIONS  AND  CRITERIA 
A.  BACKGROUND 

A comprehensive  search  of  current  literature  was  under- 
taken to  determine  if  a model  for  the  design  of  management 
information  and  control  systems  existed.  For  this  thesis, 
the  term  "model"  is  defined  as  a set  of  formulae  or  consid- 
erations which  when  entered  with  appropriate  data  would 
result  in  a specific  MICS  design.  No  such  model  was  found. 
What  was  discovered  was  a recurring  description  of  the 
process  of  MICS  development  as  briefly  outlined  in  the 
methodology  and  the  stipulation  of  certain  information 
characteristics  and  classifications  and  system  characteris- 
tics which  when  analyzed  in  the  light  of  user  requirements 
and  constraints  would  yield  the  general  design  of  the  appro- 
priate MICS  for  the  desired  application.  Of  note  is  the 
fact  that  virtually  all  the  literature  encountered  dealt 
'with  the  private  sector  and  as  such  emphasized  the  goals  of 
the  business  enterprise  and  interactions  with  the  market 
place.  This  orientation  made  it  difficult  to  apply  all  the 
principles  expressed  to  the  Government  perspective. 

The  role  of  the  SPO/NWC  Manager  was  described  briefly 
in  Chapter  I as  one  of  performing  the  management  functions 
of  planning  and  controlling  to  assure  the  attainment  of 
program  goals  and  objectives.  It  was  hypothesized  that  a 
comprehensive  "system"  was  required  in  order  to  adequately 
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perform  this  role.  A "system"  is  defined  in  Webster's 
Unabridged  as  "a  complex  unit  formed  of  many  often  diverse 
parts  subject  to  a common  plan  or  serving  a common  purpose . 11 
It  would  appear  obvious  then  that  to  design  a system  to 
serve  a purpose,  a concise  definition  of  the  purpose  is 
essential.  A concise  definition  of  planning  and  control  has 
been  the  center  of  arguments  among  authors  of  management 
texts  for  years.  Particularly  useful  definitions  of  the 
planning  and  control  functions  for  use  in  information  sys- 
tems design,  however,  are  expressed  by  Robert  Anthony  and  G. 

A.  Gorry  and  M.  S.  Scott-Morton. 

B.  CONCEPTUAL  FRAMEWORKS  FOR  MICS 

1.  Robert  Anthony  Framework  for  MICS 

In  Planning  and  Control  Systems : A Framework  for 
Analysis , Anthony  addressed  the  problem  of  developing  a 
classification  scheme  that  would  allow  management  some 
perspective  when  dealing  in  the  area  of  planning  and  control 
systems.  He  developed  a framework  for  analyzing  these 
managerial  functions  or  processes  consisting  of  three  cate- 

t 

gories  and  argued  that  the  differences  among  these  categor- 
ies were  so  significant  that  the  systems  designed  for  the 
processes  would  have  substantially  different  characteristics. 

The  first  of  Anthony's  categories  of  managerial 
activities  is  "strategic  planning. " Strategic  planning  is 
defined  as  "the  process  of  deciding  on  objectives  of  the 
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organization,  on  changes  in  these  objectives,  on  the  re- 
sources used  to  obtain  these  objectives,  and  on  the  policies 
that  are  to  govern  the  acquisition,  use  and  disposition  of 
these  resources. " [2]  Anthony  made  a number  of  points  with 
respect  to  strategic  planning.  First,  it  focuses  on  the 
choice  of  objectives  for  the  organization  and  on  the  means 
required  to  achieve  these  objectives.  As  a result,  problems 
in  this  area  tend  to  involve  longer  range  planning  and 
therefore  require  prediction  as  to  the  future  of  both  the 
organization  and  its  environment.  Secondly,  the  strategic 
planning  process  usually  involves  a small  number  of  high- 
level  people  who  must  operate  in  a nonrepetitive  and  often 
very  creative  way.  Thirdly,  the  types  of  decisions  to  be 
made  involve  many  variables,  and  are  usually  unstructured 
and  irregular.  The  results  of  these  decisions  are  policies 
and  precedents  which  are  extremely  difficult  to  evaluate. 

The  second  category  defined  by  Anthony  is  manage- 
ment control.  This  process  was  defined  as  "...  the  process 
by  which  managers  assure  that  resources  are  obtained  and 
used  effectively  and  efficiently  in  the  accomplishment  of 
the  organization's  ob jectives . " [ 2]  He  stresses  three  key 
aspects  of  this  function.  First,  the  process  involves  a 
larger  number  of  persons;  managers  who  must  accomplish  their 
tasks  through  interpersonal  relations.  Secondly,  these 
tasks  are  defined  within  the  context  of  objectives  and 
policies  that  have  been  determined  in  the  strategic  planning 
process.  Thirdly,  the  relevant  criteria  for  evaluating  the 
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actions  taken  are  effectiveness  and  efficiency. 

Anthony's  third  category  is  operational  control 
which  he  defines  as  "the  process  of  assuming  that  specific 
tasks  are  carried  out  effectively  and  efficiently. " [2]  The 
basic  distinction  between  management  control  and  operational 
control  is  that  operational  control  is  concerned  with  che 
execution  of  specified  tasks,  whereas  management  control 
deals  with  the  whole  stream  of  on-going  activities  rather 
than  on  specific  tasks.  Just  as  management  control  operates 
within  policies  established  by  strategic  planning,  so  oper- 
ational control  occurs  within  a set  of  procedures  and  rules 
that  are  derived  from  both  management  control  and  strategic 
planning. 

Anthony  pointed  out  that  the  boundaries  between 
these  three  categories  are  often  not  clear.  In  spite  of 
their  limitations  and  uncertainties , however,  these  categor- 
ies are  useful  in  the  analysis  and  design  of  information 
systems . 

2 . Gorry  and  Scott-Morton  Framework 

G.  Anthony  Gorry  and  Michael  S.  Scott-Morton  have 
also  addressed  the  area  of  a conceptual  framework  for  MIS. 

In  a paper  published  in  the  Sloan  Management  Review  (Fall 
1971)  they  state  that  the  purpose  of  their  work  is  "...  to 
present  a framework  that  helps  us  to  understand  the  evolu- 
tion of  MIS  activities  within  organizations  . . . this  frame- 
work is  designed  to  be  useful  in  planning  for  information 
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systems  activities  within  an  organization  and  for  distin- 
guishing between  the  various  model  building  activities, 
models,  computer  systems  and  so  forth  which  are  used  for 
supporting  different  kinds  of  decisions ."[ 3] 

The  Gorry  and  Scott-Morton  framework  is  a two- 
dimensional  framework  which  integrates  the  managerial  func- 
tions as  defined  by  Anthony  with  decision  types  as  defined 
by  H.  A.  Simon.  In  the  New  Science  of  Management  Decision, 

Simon  is  concerned  with  the  manner  in  which  people  solve 
problems  regardless  of  their  position  within  the  organiza- 
tion. He  makes  the  distinction  between  "programmed"  and 
"nonprogrammed”  decisions.  Programmed  decisions  are  defined 
as  those  which  are  repetitive  and  routine  to  the  extent  that 
a definite  procedure  has  been  established  for  handling  them 
each  and  every  time  they  occur.  Nonprogrammed  decisions  are 
those  for  which  no  "automatic"  method  for  the  decision 
making  process  has  been  established.  They  are  by  nature 
novel  and  nonrepetitive  and  therefore  require  individual 
action  based  on  intelligent,  adaptive  problem  solving. 

Gorry  and  Scott-Morton  chose  to  use  the  terms 
"structured"  and  "unstructured"  in  lieu  of  programmed  and 
unprogrammed  in  order  to  stress  the  basic  concept  of  the 
problem-solving  activity  in  question  and  avoid  the  implica- 
tion of  computer  dependence  which  might  result  from  the  use 
of  Simon's  terminology.  They  also  included  a class  of 
decisions  which  they  called  "semi-structured."  These  deci- 
sions are  characterized  by  the  ability  to  structure  a 
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portion  of  the  decision  making  process  but  not  the  process 
in  its  entirety. 
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FIGURE  II-l. 


A pictorial  representation  of  the  Gorry  and  Scott- 


Morton  framework  is  presented  in  Figure  II-l.  While  some 


examples  are  listed  in  each  of  the  six  cells,  it  is  empha- 
sized that  the  cells  are  not  well  defined  categories  just  as 
with  the  Anthony  framework.  The  Gorry  and  Scott-Morton 
framework  merges  the  two  different  perspectives  of  mana- 
gerial activity  taken  by  Anthony  and  Simon.  Anthony's 
categorization  is  based  on  the  purpose  of  the  management 
activity,  while  Simon's  classification  is  based  on  the 
manner  in  which  the  manager  deals  with  the  problems  which 
confront  him.  The  combination  of  these  two  views  provides  a 
useful  framework  within  which  to  examine  the  purposes  and 


characteristics  of  information  systems. 
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C.  FRAMEWORK  IMPLICATIONS  ON  THE  MICS 

The  characteristics  of  managerial  activity  defined  by 
the  Anthony  and  the  Gorry  and  Scott-Morton  frameworks  have 
explicit  implications  on  information  systems  design  in  three 
general  areas:  information  requirements,  system  character- 

istics, and  the  system  design  process.  Implications  in  all 
three  of  these  areas  will  be  addressed  here;  however,  only 
the  information  requirements  considerations  will  be  addres- 
sed in  detail.  The  remaining  two  areas  will  be  discussed  at 
greater  length  in  subsequent  sections  of  this  chapter. 

1.  Information  Requirements 

Clearly,  there  are  many  choices  with  regard  to  the 
characteristics  of  information  presented  to  a decision  maker 
or  manager.  The  system  designer  must  consider  the  use  to 
which  the  information  will  be  placed  in  deciding  what  infor- 
mation to  provide.  If  the  information  requirements  of  the 
three  categories  presented  by  Anthony  are  considered,  it  can 
be  seen  that  they  are  very  different  from  one  another. 
Further,  this  difference  is  not  simply  a matter  of  aggrega- 
tion from  one  level  to  the  next  but  one  of  fundamental 
difference  in  the  characteristics  of  the  information  needed 
by  the  managers  in  these  areas. 

Strategic  planning  deals  with  broad  policies  and 
organizational  objectives.  Consequently,  the  relationship 
of  the  organization  to  its  environment  is  a matter  for 
consideration.  Also,  the  nature  of  the  activity  is  such 
that  predictions  of  the  future  are  required.  Therefore,  the 
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information  needed  by  strategic  planners  is  generally  infor- 
mation from  outside  the  organization  and  is  based  on  esti- 
mates. It  follows  that  this  information  is  relatively 
imprecise  and  of  an  aggregate  nature.  Also,  the  nonroutine 
nature  of  the  strategic  planning  process  means  that  the 
demands  for  this  information  will  be  infrequent. 

The  information  needs  for  operational  control  are 
virtually  opposite  to  those  of  strategic  planning.  Since 
this  process  deals  with  specific  task  accomplishment,  it 
requires  well  defined  and  accurate  information  which  is 
generated  internally.  This  information  must  also  be  avail- 
able on  a frequent  basis  and  in  greater  detail. 

The  management  control  process  encompasses  the 
totality  of  the  organization  and  as  such  deals  with  some 
aspects  of  strategic  planning  and  operational  control.  As  a 
result,  the  information  requirements  of  management  control 
fall  in  between  those  of  the  other  two  processes.  Anthony 
emphasizes  that  the  information  for  the  management  control 
systems  must  be  of  an  integrated  nature,  encompassing  the 
varied  and  detailed  requirements  of  the  operational  control 
system  and  the  broad  requirements  of  the  strategic  planning 
system.  He  suggests  that  the  common  denominator  is  money 
and,  therefore,  information  in  the  management  control  system 
should  be  expressed  in  monetary  terms. 

These  general  information  characteristics  and  their 
relationship  to  the  framework  are  illustrated  in  Table  II-A. 
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This  summary  is  subject  to  the  same  limitations  and  uncer- 
tainties which  are  applicable  to  the  concepts  of  management 
control,  strategic  planning  and  operational  control.  How- 
ever, it  does  illustrate  the  contention  that  the  inherent 
differences  in  the  processes  result  in  different  information 
requirements. 


CHARACTERISTICS  OPERATIONAL  MANAGEMENT  STRATEGIC 

OF  INFORMATION  CONTROL  CONTROL  PLANNING 


SCOPE 

FREQUENCY  OF  USE 

VERY  FREQUENT  

► INFREQUENT 

INFORMATION  REQUIREMENTS  BY  MANAGEMENT  FUNCTION  (3) 
TABLE  I I -A. 

The  degree  to  which  the  decision  making  process  is 
structured  or  unstructured  also  has  implications  on  the 
information  required.  If  a decision  process  is  structured 
to  the  extent  that  a model  is  in  existence  or  can  be  con- 
structed, the  model  will  identify  what  information  is  re- 
quired in  very  definite  terms.  If,  however,  the  decision 
making  process  is  unstructured,  the  information  requirements 
will  be  ill-defined  and  the  relevant  information  will  re- 
quire identification  on  a case  by  case  basis. 
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2.  System  Characteristics 


In  general  terms,  an  information  system  collects 
source  data  and  transforms  or  converts  it  into  meaningful 
and  useful  forms.  It  is  somewhat  analogous  to-  the  process 
of  purchasing  raw  materials,  producing  finished  goods,  and 
distributing  the  finished  products  to  customers.  Drawing  on 
this  analogy,  the  system  can  be  viewed  as  having  three 
stages:  inputs,  processing  and  outputs.  The  manner  in 

which  these  stages  are  accomplished  is  influenced  by  the 
needs  of  the  user  as  characterized  by  his  position  in  the 
framework.  Therefore,  the  method  of  operation  of  the  system 
and  the  system  characteristics  will  in  some  respects  be 
driven  by  these  same  considerations. 

For  example,  the  input  or  data  collection  techni- 
ques appropriate  for  operational  control  would  be  dictated 
by  the  need  for  current  information  and  frequent  updating. 

An  on-line  computer  terminal  would  fulfill  these  require- 
ments but  would  not  be  necessary  for  the  input  of  data  to  a 
system  designed  for  strategic  planning.  The  basic  differ- 
ences in  the  characteristics  of  the  information  required  by 
the  various  cells  in  the  frameworks  indicate  that  quite 
different  data  base  or  storage  arrangements  are  required  to 
support  the  decisions  encountered  in  each  area.  Strategic 
planning  decisions  require  a data  base  with  less  accurate 
information  which  may  be  subjected  to  complex  simulation 
models  while  operational  control  decisions  require  larger 
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amounts  and  more  detailed  information  processed  through  less 
complex  models. 


It  can  be  seen  that  the  frameworks  provide  a 
perspective  from  which  to  view  information  systems  methods 
of  operation  and  characteristics  to  determine  the  proper 
system  to  adequately  fulfill  the  users'  needs.  A more 
detailed  description  of  system  characteristics  which  the 
user  and  system  designer  should  consider  in  the  design  of  a 
specific  system  will  be  presented  in  a subsequent  section  of 
this  chapter. 

3 . System  Design  Process 

The  implications  of  the  frameworks  on  the  design 
process  are  in  the  areas  of  the  organizational  level  to  be 
served,  the  types  of  models  to  be  employed  and  the  goals  of 
the  system  under  design. 

Individuals  within  an  organization  typically  make 
different  types  of  decisions  depending  upon  their  organiza- 
tional level.  It  would  be  rare  to  find  first  line  super- 
visors involved  in  strategic  planning,  and  conversely,  the 
president  or  head  of  an  organization  should  make  relatively 
few  operational  decisions.  Thus,  if  the  level  of  management 
for  which  the  system  is  to  be  designed  is  well  identified, 
the  Anthony  framework  is  useful  in  presenting  considerations 
to  be  made  with  respect  to  information  requirements  and 
system  characteristics.  The  real  point  here  is  that  the 
design  of  an  information  system  depends  heavily  on  the 
individuals  who  will  use  it. 
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The  sources  of  models  for  operational  control  are 
numerous.  There  is  a history  of  applications,  the  problems 
are  often  similar  across  organizations  and  the  systems  are 
well  documented.  In  strategic  planning,  and  to  a lesser 
extent  management  control,  systems  are  still  in  the  early 
stages  of  development.  Models  tend  to  be  individual  and  are 
derived  from  the  managers  involved.  It  is  a model  creation 
process  as  opposed  to  a model  application  process.  In 
general,  it  can  be  said  that  the  information  system's  prob- 
lem in  the  structured  area  is  basically  one  of  implementing 
a given  general  model  in  a particular  organizational  con- 
text; however,  work  in  the  unstructured  areas  is  much  more 
involved  with  model  development  and  formalization. 

Gorry  and  Scott-Morton  state  that  to  improve  the 
quality  of  decisions  a systems  designer  can  seek  to  improve 
the  quality  of  the  information  inputs  or  to  change  the 
decision  process,  or  both. [3]  If  an  appropriate  model  is  in 
existence,  it  would  follow  that  better  information  would 
provide  better  decisions  or  control.  However,  in  the  case 
of  an  unstructured  process  the  improved  information  may  not 
be  as  fruitful  (see  ACKOFF  [4]).  This  contrast  implies  that 
different  design  goals  are  appropriate  for  different  appli- 
cations within  the  context  of  the  framework. 

The  goal  of  an  information  system  in  a structured 
setting  is  usually  to  improve  the  processing  and  quality  of 
information.  In  unstructured  situations  the  goal  of  the 
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information  system  may  be  primarily  to  improve  the  presenta- 
tion of  information  to  the  manager  and  to  help  in  structur- 
ing the  problem. 


The  system  design  process  will  be  dealt  with  more 
extensively  in  a subsequent  portion  of  this  chapter.  Again, 
the  perspective  gained  by  the  adoption  of  the  framework  will 
be  helpful  in  addressing  specific  areas  of  system  design  to 
fulfill  the  particular  users'  requirements. 


D.  INFORMATION  SYSTEM  CHARACTERISTICS  AND  CONSIDERATIONS 


The  first  section  of  this  chapter  dealt  with  the  por- 
tion of  the  Webster  definition  of  a system  which  included 
the  "common  purpose"  for  which  an  information  system  would 
be  proposed  and  designed.  The  second  section  addressed  some 
of  the  implications  of  the  "common  purpose"  upon  the  system 
structure  and  characteristics.  This  section  will  expand 
upon  those  system  physical  characteristics  which  are  in- 
cluded in  the  Webster  definition  as  "a  complex  unit  formed 
of  many  often  diverse  parts  ..."  and  address  the  various 
considerations  which  must  be  undertaken  in  evaluating  those 
physical  characteristics  with  respect  to  a particular  MICS 
design. 

1.  System  Characteristics 

An  information  system  was  previously  defined  as  a 
means  of  transforming  or  converting  source  data  into  meaning- 
ful and  useful  information.  This  transformation  can  be 
viewed  from  an  operational  perspective,  i.e.,  what  functions 
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or  operations  must  be  performed,  and  from  a technical  per- 
spective, i.e.,  through  what  methods  these  operations  can  be 
performed. 

a.  System  Operations 

While  the  exact  sequence  of  operations  required 
to  convert  particular  items  of  data  into  information  may 
vary  to  some  extent,  a general  set  of  operations  can  be 
identified.  Burch  and  Strater  contend  that  these  operations 
include  capturing,  verifying,  classifying,  arranging  (sort- 
ing) , summarizing,  calculating,  storing,  retrieving,  repro- 
ducing, and  disseminating/communicating .[ 5 ] A description 
of  these  operations  and  a grouping  in  terms  of  input,  out- 
put, and  processing  is  presented  in  Table  II-B. 


INPUT 

CAPTURING 

RECORDING  OF  DATA  FROM  AN  EVENT  IN  SOME  FORM  OF 
DOCUMENTATION 

VERIFYING 

VALIDATING  THAT  DATA  WAS  CAPTURED  CORRECTLY 

PROCESSING 

CLASSIFYING 

PLACING  OATA  INTO  SPECIFIC  CATEGORIES  WHICH 
PROVIDE  MEANING  TO  THE  USER 

ARRANGING 

(SORTING) 

PLACING  DATA  ELEMENTS  IN  A SPECIFIED  SEQUENCE 

SUMMARIZING 

COMBINING  OR  AGGREGATING  DATA  ELEMENTS  EITHER 
MATHEMATICALLY  OR  LOGICALLY 

CALCULATING 

COMPUTING  OR  OTHER  ARITHMETIC  AND/OR  LOGICAL 
MANIPULATING  OF  THE  DATA 

STORING 

PLACING  DATA  ONTO  SOME  STORAGE  MEDIA  FOR  FUTURE 
RETRIEVAL 

OUTPUT 

RETRIEVING 

SEARCHING  OUT  AND  GAINING  ACCESS  TO  SPECIFIC  DATA 
ELEMENTS  FROM  STORAGE 

REPRODUCING 

DUPLICATING  DATA  FROM  ONE  MEDIUM  TO  ANOTHER 

DISSEMINATING/ 

COMMUNICATING 

TRANSFERING  DATA  FROM  ONE  PLACE  TO  ANOTHER 

INFORMATION  SYSTEMS  OPERATIONS  AND  DESCRIPTIONS 
TABLE  II-B 
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b.  Systems  Methods 


Advances  in  technology  have  resulted  in  many 
devices  that  can  be  utilized  to  perform  the  ten  basic  data 
operations  as  outlined  by  Burch  and  Strater.  The  informa- 
tion system  in  most  large  organizations  is  generally  com- 
posed of  a variety  of  technological  and  manual  methods. 

Based  on  the  level  of  automation  represented,  Burch  and 
Strater  presented  four  broad  categories  of  data  processing 
methods  which  they  defined  as  (1)  manual,  (2)  electromech- 
anical, (3)  punched  card  equipment,  and  (4)  electronic 
computer. 

In  the  manual  method  all  of  the  data  operations 
are  performed  by  hand  with  the  aid  of  basic  devices  such  as 
pencil,  paper,  vis-boards,  etc.  The  electromechanical 
method  is  actually  a combination  of  man  and  machine.  Ex- 
amples of  this  method  would  be  an  operator  working  at  a tub 
file,  calculator  or  duplicating  machine.  The  punched  card 
equipment  method  is  sometimes  referred  to  as  the  Electronic 
Accounting  Machine  (EAM)  method.  The  principal  recording 
medium  is  the  punched  card.  A number  of  cards  which  contain 
data  about  a similar  subject  are  grouped  together  in  a tray 
of  cards  usually  termed  a file.  A typical  punched  card 
system  is  comprised  of  any  or  all  of  the  following  devices: 
key  punch,  verifier,  sorter,  collator,  reproducer,  account- 
ing machine,  calculating  punch,  interpreter,  and  summary 
punch.  It  is  worthy  of  note  here  that  the  recent  advances 
in  small  computer  technology  are  rapidly  obsoleting  punched 
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card  equipment  as  a primary  data  processing  method;  however 
many  of  these  systems  are  still  in  existence. 


In  general,  the  preceding  methods  utilize  an 
individual,  or  a particular  machine  to  perform  each  data 
operation  separately.  The  development  of  the  electronic 
computer  allowed  one  machine  to  perform  most  of  the  data 
operations  without  intermittent  human  intervention.  The 
electronic  computer,  as  the  term  will  be  used  in  this 
thesis,  means  a configuration  of  input  devices,  a central 
processing  unit  (CPU)  and  output  devices.  There  is  a large 
variety  of  hardware  available  in  a myriad  of  electronic 
computer  system  configurations.  It  is  not  the  authors' 
intention  to  explore  or  describe  these  devices  in  detail  but 
rather  to  point  out  their  capabilities  which  warrant  consid- 
eration in  the  development  of  a management  information  and 
control  system  application. 

The  four  methods  of  data  processing  which 
have  been  briefly  described  above  are  illustrated  in  Table 
II-C,  along  with  their  relationship  to  the  data  operations 
they  perform. 

2 . Systems  Considerations 

The  old  adage  of  "to  get  the  right  answers,  you 
must  ask  the  right  questions"  is  particularly  germane  to  the 
design  of  a MICS.  In  order  to  obtain  a system  which  will 
satisfy  the  users'  requirements,  the  user  and  designer  must 
be  able  to  translate  the  users'  requirements  into  system 
capabilities.  As  pointed  out  previously,  no  specific  model 
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perations  Capturing  Disseminating 

\ and  Initial  and 


1 

for  designing  a MICS  was  discovered  in  the  literature; 
however,  a number  of  considerations  in  the  accomplishment 
of  an  MICS  design  were  presented  by  various  authors.  These 
considerations  will  be  discussed  from  the  viewpoint  of  the 
systems  input,  processing  and  output  functions, 
a.  Input  Considerations 

The  system  input  functions  or  operations  are 
shown  in  Table  II-B  as  capturing,  initially  recording  and 
verifying  the  data  to  be  entered  into  the  system.  An  initial 
input  consideration  is  the  number  and  organizational  level 
of  the  users  of  the  system.  How  many  people  will  actually 
require  the  ability  to  enter  data?  Who  will  actually  enter 
the  data?  Will  some  data  be  sensitive  and  therefore  require 
inputing  from  only  designated  people?  What  resources  for 
data  gathering  and  entering  are  currently  in  existence  or 
are  attainable?  Does  the  user  manager  want  to  have  the 
capability  to  enter  data  himself? 

The  verification  function  brings  forth  two 
opposing  viewpoints.  One  viewpoint  is  that  a system  which 
segregates  the  data  collecting,  recording,  and  entry  func- 
tions will  provide  more  chance  for  the  detection  of  errors. 

The  opposite  viewpoint  is  that  the  more  people  or  iterations 
involved,  the  greater  the  likelihood  errors  will  occur  and 
remain  undetected.  Both  these  viewpoints  have  merit  and 
require  consideration. 

The  source  of  the  input  may  have  a significant 
impact  on  the  requirement  for  verif ication . If  an  EAM 
or  computer  application  is  to  be  used,  can  the  operator  read 
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handwritten  input  data  or  must  it  be  directly  machinable? 

The  application  of  this  function  to  the  system  should  be 
evaluated  in  light  of  the  above  as  well  as  in  the  context  of 
the  conceptual  framework  previously  discussed,  i.e.,  the 
appropriate  accuracy  of  the  information  required, 
b.  Processing  Considerations 

The  processing  functions  as  depicted  in 
Tables  II-B  and  II-C  make  up  the  majority  of  the  system's 
operations.  A primary  consideration  in  the  total  system 
operation  and  in  the  processing  functions  in  particular  is 
time.  The  total  system  time  and  the  processing  time  can  be 
characterized  in  two  ways:  response  time  and  frequency. 

Response  time  or  turnaround  time  can  be  de- 
scribed as  the  measure  of  total  time  required  to  complete  a 
cycle  of  the  system.  In  the  case  of  the  processing  func- 
tions, this  would  be  the  amount  of  time  required  to  accom- 
plish the  necessary  processing  operations  appropriate  for 
the  data  input  and  desired  output.  For  the  total  system 
this  would  include  the  time  required  for  the  input  functions 
and  output  functions  as  well  as  the  time  required  by  the 
processing  functions. 

Frequency  is  the  measure  of  how  often  the 
system  cycle  is  completed.  The  consideration  here  is  both 
in  terms  of  user  requirements  and  system__capabilities . How 
often  does  the  manager  require  the  processing  functions 
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performed?  This  will  depend  upon  his  position  as  depicted 
in  the  conceptual  framework  and  the  framework  implied  infor- 
mation requirements.  The  system  capability  for  frequency  of 
operation  will  be  tied  to  the  response  time  and  the  re- 
sources available  to  iterate  the  process.  In  general,  both 
the  response  time  and  frequency  capabilities  of  a system  are 
improved  with  higher  applications  of  automation  given  a 
reasonable'  volume  of  data  to  be  manipulated. 

Another  consideration  relative  to  the  process- 
ing functions  is  volume.  The  quantity  of  data  which  must 
undergo  the  various  operations  must  be  determined.  The 
number  of  categories  to  be  used  for  the  classifying  opera- 
tion must  be  identified,  and  the  amount  and  complexity  of 
summarizing  and  calculating  activity  must  be  specified.  The 
larger  the  volume  of  the  processing  operations  the  more 
resources,  be  it  more  people  or  more  sophisticated  equip- 
ment, which  will  be  required  to  meet  the  users’  demands. 

Storage  and  retrieval  requirements  must  also  be 
considered.  The  volume  and  detail  of  the  files  to  be  main- 
tained should  be  evaluated.  If  a computer  based  system  is 
being  considered,  an  estimate  of  how  long  the  file  data 
should  be  retained  and  the  media  for  storage  are  important  - 
file  storage  on  computers  is  expensive.  If  the  data  can  be 
printed  and  stored  in  file  cabinets  where  only  occasional 
access  is  necessary,  it  will  cost  far  less  than  a computer 
direct  access  storage  device  (DASD ) such  as  magnetic  disc, 
drum,  or  data  cell  which  would  provide  instantaneous  access. 
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A trade-off  must  be  made  between  hardware  cost  and  slower 


access  to  data. 

There  are  two  different  approaches  to  the 
accomplishment  of  the  processing  functions  in  an  electronic 
computer  based  system:  batch  processing  and  on-line  proces- 

sing. Batch  processing  is  characterized  by  a periodic 
(daily,  weekly,  monthly,  or  other  convenient  time  frame) 
performance  of  the  processing  functions  on  the  data  accumu- 
lated over  the  prescribed  interval.  An  on-line  system 
processes  each  transaction  as  it  occurs.  Although  these  two 
approaches  to  the  processing  function  tend  to  be  mutually 
exclusive,  there  are  examples  of  batched  data  transaction 
being  input  on  on-line  systems. 

There  are  practical  differences  betveen  batch 
and  on-line  systems  in  a number  of  areas.  Batch  systems 
usually  have  separate  data  collection  and  preparation  activ- 
ities such  as  keypunching  source  documents  to  punch  cards, 
preparing  magnetic  tape  from  punch  cards,  record  sorting, 
and  so  forth.  On-line  systems,  on  the  other  hand,  usually 
collect  data  as  transactions,  occur  and  transmit  it  directly 
to  the  computer  without  any  intervening  operations. 

Batch  processing  often  involves  reading  the 
appropriate  program  into  core  storage  and  performing  certain 
housekeeping  activities  before  the  data  can  be  processed. 
Processor  set-up  activities  are  minimized  in  an  on-line 
system  since  the  system  is  actually  maintained  in  a state  of 
constant  readiness. 
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In  batch  processing  every  single  master  record 
must  be  read  into  fast  memory  (core  storage)  for  record  key 
comparison  with  the  current  transaction  record.  If  the 
number  of  transaction  records  is  small,  relative  to  the 
total  number  of  records  in  the  master  file,  processor  effi- 
ciency may  be  rather  poor.  Under  the  same  circumstances, 
on-line  processing  is  more  efficient  since  only  the  active 
master  records  are  actually  accessed.  An  additional  consid- 
eration, however,  is  the  problem  of  idle  computer  time  when 
no  transactions  are  entering  an  on-line  system.  Overall, 
batch  processing  makes  somewhat  more  efficient  use  of  pro- 
cessor capacity  than  on-line  processing. 

Batch  processing  usually  requires  fewer  types 
and  smaller  capacity  equipment  than  on-line  systems.  Remote 
terminals  and  auxiliary  storage  capacity  are  not  necessarily 
required  with  batch  systems,  but  are  normally  needed  for  on- 
line systems.  The  processor  capacity  of  on-line  systems  may 
need  to  be  larger  in  order  to  handle  peak  transaction  activ- 
ity loads.  Also,  the  computer  operating  control  systems 
(software)  for  on-Line  systems  tend  to  be  more  complex, 
expensive,  and  troublesome  than  that  required  for  batch 
systems . 

On-line  inquiry  combined  with  off-line  (batched) 
updating  represents  an  intermediate  state  of  complexity  that 
can  prove  adequate  in  many  instances.  Here  the  data  base  is 
updated  by  conventional  off-line  processing  and  made  avail- 
able for  management  inquiries  during  the  working  day  with 
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the  restriction  that  no  updating  occur  during  that  time  and 
with  the  day's  transactions  batched  for  entry  in  the 
evening . 

c.  Output  Considerations 

The  considerations  pertinent  to  the  output 
functions  of  the  system  include  a number  of  the  same  consid- 
erations' set  forth  in  terms  of  the  other  system  functions. 

An  acceptable  timeframe  in  which  to  actually  retrieve, 
reproduce  and  disseminate  the  required  information  must  be 
defined  by  the  user.  The  number  and  content  of  output 
reports  must  be  addressed.  Can  the  users'  requirements  be 
satisfied  with  a specific  number  of  reports  at  prescribed 
intervals  or  is  a free  form  interrogation  of  stored  data 
required?  These  considerations  will  have  a direct  effect  on 
the  processing  method  of  a computer  system.  The  reports 
generated  by  a batch  system  are  necessarily  tied  to  the  same 
cycle  as  that  of  the  input  and  processing  functions  (e.g., 
daily,  weekly,  etc.).  The  manager  is  then  tied  to  this 
schedule  as  well. 

The  format  of  output  reports  should  be  addres- 
sed. Must  the  reports  be  hand  copy  or  can  quick-look  cath- 
ode ray  tube  (CRT)  displays  suffice?  If  hard  copy  reports 
are  needed,  what  will  the  physical  requirements  be  in  terms 
of  size  and  format?  Will  charts  or  graphs  need  to  be  plot- 
ted or  will  output  be  in  straightforward  text?  The  volume 
of  output  reports  required  and  their  dissemination  should 
also  be  included  in  the  evaluation. 
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The  need  for  output  security  should  be  deter- 
mined. Will  some  of  the  output  information  be  considered 


sensitive  and  therefore  require  restricted  access?  The 
methods  of  insuring  this  security  will  vary  depending  upon 
the  type  and  design  of  the  information  system  selected. 

While  restriction  of  output  data  may  be  more  difficult  in  an 
automated  system  than  in  a manual  one,  provisions  can  be 
made  to  preclude  free  access  to  certain  outputs. 

E.  THE  INFORMATION  SYSTEM  DESIGN  PROCESS 

Previously  the  authors  ‘indicated  that  the  character- 
istics of  the  Anthony  and  the  Gorry  and  Scott-Morton 
frameworks  have  explicit  implications  on  the  information 
system  design  in  three  general  areas:  information  require- 

ments, system  characteristics  and  the  system  design  process. 
To  this  point,  the  system  information  requirements  and 
system  characteristics/capabilities  have  been  discussed. 

This  section  will  pursue  the  system  design  process  itself. 

1 . Definition  of  the  Design  Process 

The  design  process  is  what  ties  the  managerial 
function  of  planning  and  control,  information  characteris- 
tics and  requirements,  and  information  systems'  characteris- 
tics and  capabilities  together  to  produce  a desired  MICS. 
"Systems  design  can  be  defined  as  the  drawing,  planning, 
sketching,  or  arranging  of  many  separate  elements  into  a 
viable,  unified  whole. "[5]  In  a MICS  this  can  be  viewed  as 
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the  amalgamation  of  management  functions  and  requirements 
with  information  systems  capabilities. 

The  Survey  and  Requirements-  phases  of  the  MIS 
development  cycle  as  outlined  in  Chapter  One  consists  of  a 
systems  analysis  which  addresses  the  questions  of  what  the 
system  is  doing  and  what  it  should  be  doing  to  meet  user 
requirements.  The  systems  design  process  is  concerned  with 
how  the  system  is  constructed  to  meet  these  requirements. 

The  development  cycle  also  shows  that  the  design  process  is 
a long,  sequential  one  which  starts  with  a vary  macro  view- 
point in  the  requirements  phase  and  gradually  defines  and 
refines  the  system  requirements  into  a final  form  capable  of 
implementation . 

2 . Design  Approaches 

As  indicated  at  the  outset  of  this  chapter,  no 
specific  model  for  the  design  of  a MICS  was  found  in  the 
literature.  The  admission  of  the  lack  of  a singular  model 
is  perhaps  best  illustrated  by  the  description  of  the  design 
process  presented  by  Burch  and  Strater.  They  state  that  "in 
order  to  design  a system  the  analyst  must  possess  knowledge 
related  to  the  following  subjects:  1)  organizational  re- 

sources, 2)  user  information  requirements,  3)  other  systems 
requirements,  4)  methods  of  data  processing,  5)  data  opera- 
tions, and  6)  design  tools.  To  produce  a systems  design, 
the  analyst  must  apply  reason  and  creativity  to  these  ele- 
ments of  knowledge. " [5]  Figure  II-2  provides  a pictorial 
representation  of  this  relationship. 
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AN  ILLUSTRATION  OF  THE  ELEMENTS  COMPRISING  THE  DESIGN 
PROCESS  FOR  AN  INFORMATION  SYSTEM  (5) 

FIGURE  II-2 . 

a.  Burch  and  Strater  Approach 

Burch  and  Strater  do,  however,  outline  some 
basic  steps  in  their  own  approach  to  a design  process. 

These  steps  include:  1)  defining  the  system  goal,  2)  devel- 

oping a conceptual  model,  3)  applying  organizational  con- 
straints, 4)  defining  data  processing  activities,  and  5) 
preparing  the  System  Design  Proposal. 

Defining  the  system  goal  is  a result  of  the 
findings  in  the  Survey  and  Requirements  phases  of  systems 
analysis.  The  goal  or  goals  need  not  be  stated  in  specific 
informational  requirements  but  rather  in  the  purpose  or 
desired  result  of  the  implementation  of  the  system. 

Developing  a conceptual  model  of  the  system  is 
nothing  more  than  a gross  depiction  of  the  inputs  and  de- 
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sired  outputs  of  the  system  and  the  indication  that  some 
processing  is  required  to  effect  thik  conversion. 

Organizational  constraints  are  defined  in  terms 
of  resources  available.  These  resources  can  take  the  form 
of  manpower,  machines,  money,  material  or  methods.  Normally 
the  information  system  must  vie  with  other  activities  to 
obtain  the  necessary  resources.  This  fact  leads  the  manager 
and  systems  analyst  to  consider  cost/effectiveness  to  the 
organization  in  the  design  and  development  of  the  system. 

In  defining  the  data  processing  activities 
which  the  system  requires  Burch  and  Strater  contend  that  you 
must  begin  with  the  identification  of  the  desired  outputs  of 
the  system.  The  next  step  is  to  list  the  specific  informa- 
tion fields  required  to  prepare  that  output  arid  identify  the 
specific  input  data  required  to  develop  those  fields.  Then 
the  processing  operations  which  will  convert  the  inputs  to 
the  desired  outputs  must  be  addressed  and  defined.  Having 
completed  these  steps  for  all  desired  outputs,  the  analyst 
should  then  consider  the  data  base  (file  system  and  struc- 
ture) and  control  points  necessary  to  support  the  outlined 
system  design. 

Earlier,  the  point  was  made  that  the  informa- 
tion needs  of  managers  at  different  levels  of  the  Anthony 
framework  were  very  different  from  one  another  and  that  this 
difference  was  one  of  fundamental  difference  of  characteris- 
tics, not  just  a matter  of  aggregation.  This  difference  is 
reflected  in  the  Burch  and  Strater  design  process  of  the 
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system  through  the  "tailoring"  of  the  information  system  to 
the  users'  requirements.  Burch  and  Strater  present  several 
specific  methods  for  tailoring  the  information  system  to  the 
requirements  of  an  organization.  These  methods  are  useful 
regardless  of  the  overall  structure  of  the  information 
system,  and  though  presented  individually,  are  also  appli- 
cable in  varying  degrees  of  combinations  to  meet  specific 
user  requirements. 

Burch  and  Strater  contend  that  the  effective- 
ness of  an  information  system  can  be  improved  by  the  follow- 
ing five  basic  methods:  1)  filtering  method,  2)  monitoring 

method,  3)  modeling  method,  4)  interrogative  method,  and  5) 
extern-al  method.  The  purpose  of  each  of  these  methods  is  to 
provide  the  user  the  information  required  in  the  most  effi- 
cient and  effective  way  possible. 

The  filtering  method  is  based  on  the  premise 
that  various  levels  of  decision  makers  require  various 
levels  of  detail  information  as  outlined  in  both  the  Anthony 
and  Gorry  and  Scott-Morton  frameworks.  Ideally,  the  infor- 
mation system  should  be  designed  to  permit  the  filtering  of 
selected  data  elements  from  the  data  base  so  that  each 
decision  maker  can  obtain  the  level  of  detail  appropriate  to 
his  or  her  individual  needs. 

The  monitoring  method  is  another  alternative 
for  reducing  the  amount  of  data  managers  receive  while  still 
increasing  the  amount  of  relevant  information  at  their 
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disposal.  Instead  of  producing  streams  of  data  to  be  han- 
dled by  the  manager,  the  information  system  monitors  the 
data  and  provides  informational  outputs  to  the  user  on  a 
predetermined  basis.  The  three  basic  ways  to  implement  the 
monitoring  method. are:  1)  variance  reporting,  2)  programmed 

decision  making,  and  3)  automatic  notification. 

Variance  reporting  requires  the  establishment 
of  normative  values  of  performance  and  an  acceptable  amount 
of  deviation  (variance)  from  that  norm.  When  the  acceptable 
variance  is  exceeded  the  system  automatically  prepares  a 
report  to  the  responsible  manager. 

Programmed  decision  making  involves  the  use  of 
the  system  to  execute  routing  decisions  based  on  predeter- 
mined check  points  or  values.  Only  those  items  which  exceed 
the  parameters  of  the  decision  model  would  be  referred  to 
the  manager  for  resolution.  This  method  is  most  applicable 
to  the  structural,  operational  level  of  decisions  as.  depic- 
ted in  the  Gorry  and  Scott-Morton  framework. 

The  automatic  notification  method  is  used  to 
take  advantage  of  the  vast  memory  capabilities  of  computors . 
The  system  merely  monitors  a large  file  of  data  and  presents 
information  on  a predetermined  basis.  For  example,  a pri- 
oritized list  of  tasks  to  be  accomplished  can  be  input  in 
the  system,  and  as  each  task  is  completed  the  system  will 
direct  the  user  as  to  which  task  must  be  undertaken  next. 

The  modeling  method  utilizes  various  logico- 
mathematical  models  to  transform  data  elements  into  desired 
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information.  They  are  used  primarily  to  provide  information 
of  a predictive  nature  based  upon  the  model  parameters  and 
the  historical  information  furnished  by  the  user.  This 
method  would  normally  be  used  by  strategic  planners  and  is 
constrained  by  the  accuracy  and  capabilities  of  the  model 
employed. 

The  interrogative  method  relies  on  the  user  to 
format  a specific  inquiry  to  the  system  to  meet  a specific 
but  previously  unanticipated  requirement.  The  system  does 
not  disseminate  information  until  a specific  request  is 
received.  While  the  concept  here  would  allow  for  the  ulti- 
mate in  providing  relevant  data  to  the  manager,  the  system 
requires  an  expensive  investment  in  data  processing  re- 
sources and  an  extraordinarily  large  data  base  in  order  to 
respond  to  the  unlimited  or  unstructured  requests  of  the 
user. 

The  external  method  refers  to  gathering  infor- 
mation which  is  generated  outside  of  the  organization.  As 
organizations  become  larger  and  more  complex,  the  outside 
environment  will  become  of  greater  importance  and  external 
information  has  to  be  communicated  in  a formal  manner  rather 
than  on  occasional  collections  and  observations  of  the 
managers  themselves.  This  method  is  obviously  directed 
toward  the  strategic  decision  maker, 
b.  Wilkinson  Approach 

Dr.  Joseph  W.  Wilkinson  outlines  three  differ- 
ent design  approaches  in  his  article  "Classifying  Information 
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Systems"  which  was  published  in  the  Journal  of  Systems 
Management,  April,  1973.  [6]  Dr.  Wilkinson  contends  that  an 
information  system  may  be  simultaneously  viewed  as  a data 
converter,  a decision-oriented  network,  and  a data  base. 
These  three  views  correspond  respectively  to  what  he  terms 
"the  three  phases  in  the  evolution  of  information  system 
design"  which  has  occurred  over  the  past  twenty  years. 

These  three  phases  are:  1)  designing  efficient  operating 

systems,  2)  designing  output-oriented  scheduled  reporting 
systems,  and  3)  designing  input-oriented  demand  reporting 
systems . 

These  three  perspectives  and  corresponding 
design  approaches  appear  to  fit  well  within  the  Anthony  and 
the  Gorry  and  Scott-Morton  frameworks.  The  perspective  of 
the  system  as  a data  converter  corresponds  to  the  focus  upon 
designing  information  systems  in  support  of  the  operational 
level  where  the  objective  is  to  provide  efficient  data 
conversion  operations  within  Well-defined  bounds.  The 
particular  activity  which  this  type  of  MIS  is  to  serve  is 
normally  a structured  one  and  therefore  the  design  process 
becomes  one  of  merely  specifying  the  data  collection,  data 
processing  and  output  data  communication  operations  as 
dictated  by  the  structure. 

The  perspective  of  the  decision-oriented  net- 
work appears  to  correspond  with  Gorry  and  Scott-Morton ' s 
categories  of  structured  or  semi-structured  management  con- 
trol. This  decision-oriented  network  viewpoint  emphasizes 
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the  regularly  recurring  flows  of  data  and  information 
between  the  operational  level  and  the  decision-making  level 
which  enable  the  managers  to  make  planning  and  control 
decisions.  The  design  process  as  described  by  Wilkinson  in 
this  decision-oriented  network  perspective  is  an  output- 
oriented  approach  in  which  the  initial  effort  is  devoted  to 
determining  what  information  is  needed  by  whom,  how  often  it 
is  needed,  etc.  When  the  characteristics  of  the  needed 
information  are  fully  specified  the  system  designers  work 
backwards  to  specify  the  input  data  and  conversion  processes 
necessary  to  provide  that  information-.  A basic  assumption 
underlying  this  approach  is  that  regularly  scheduled  reports 
can  provide  managers  with  the  information  they  need  for 
successful  completion  of  most  of  their  responsibilities.. 

The  data  base  perspective  emphasizes  the  col- 
lecting and  organizing  of  data  for  use  by  managers  in  de- 
cision making  in  an  unpredictable  environment.  This  outlook 
can  be  interpreted  as  the  unstructured  managerial  control 
level  or  the  strategic  planning  level.  The  input-oriented 
design  approach  which  Wilkinson  contends  is  necessary  to 
support  this  perspective  concentrates  on  data  collection  and 
storage  for  random  retrieval.  The  assumption  underlying 
this  approach  is  that  the  environment  of  the  manager  is  so 
dynamic  that  he  cannot  know  in  advance  what  decisions  must 
be  made  and  therefore  he  cannot  determine  and  specify  much 
of  the  information  he  needs.  Consequently,  the  design 
approach  is  to  select  and  organize  for  easy  retrieval  a 
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massive  variety  of  data  that  has  some  probability  of  being 
needed.  As  the  manager  encounters  an  unexpected  decision, 
the  system  provides  the  requested  information  promptly  in  a 
flexible  reporting  format. 

3 . Summary 

* The  use  of  the  above  design  approaches  will  aid 

4 

the  information  system  designer  in  bridging  the  gap  between 
user  requirements  and  system  definition.  By  highlighting 
the  users'  perspective  and  relevant  information  needs  and 
relating  them  to  a method  or  combination  of  methods  for 
providing  that  information  the  designer  will  begin  to  define 
the  system  capability  requirements  in  terms  of  system  consid- 
erations and  system  characteristics. 

F.  CRITERIA  FOR  SELECTION  OF  SYSTEM  TYPE 

A MICS  can  be  designed  which  will  meet  the  users 1 
requirements  in  a variety  of  ways  as  shown  in  the  previous 
section.  Furthermore,  the  system  design  can  be  specified 
without  stipulation  of  the  data  processing  method  in  most 
cases.  How  then  do  the  user  and  system  designer  decide  upon 
the  proper  method  for  a particular  application? 

Burch  and  Strater  contend  that  this  selection  requires 
consideration  of  both  processing  requirements  of  the  system 
and  performance  capabilities  of  each  processing  method.  The 
processing  requirements  can  be  viewed  as  being  determined 
by:  1)  the  volume  of  data  elements  involved,  2)  the  com- 

plexity of  the  required  data  processing  operations, 
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3)  processing  time  constraints,  and  4)  computational  demands. 


As  in  other  aspects  of  the  MICS  design  and  development,  no 
specific  model  exists  to  determine  the  exact  degree  or  level 
of  these  requirements  which  corresponds  to  a given  process- 
ing method.  However,  it  can  be  stated  in  general  that  as 
the  volume  of  data  increases,  as  complexity  increases,  as 
time  constraints  become  more  severe,  and  as  computational 
demands  become  more  sophisticated,  an  increased  level  of 
automation  is  warranted.  Not  all  these  conditions  need  be 
present.  It  may  be  that  a single  processing  requirement  is 
so  dominant  that  an  advanced  level  of  automation  is  war- 
ranted on  that  parameter  alone. 


Data 

Processing 

^\Method 

Factors 

Manual 

Electromechanical 

Punched  Card 

Computer 

Initial  Investment 

Low 

* Moderately  low 

Medium 

High 

Set  Up 

Low 

Moderately  low 

Moderately  high 

High 

Conversion 

Low 

Medium 

Medium 

High 

Skilled  Personnel 

Low 

Moderately  low 

Medium 

High 

Variable  Cost 

High 

Medium 

Moderately  low 

Low 

Modularity 

High 

Low 

Moderately  low 

Medium 

Flexibility 

High 

Low 

Medium 

Low 

Versatility 

Low 

Low 

Medium 

High 

Processing  Speed 

Low 

Moderately  low 

Medium 

High 

Computational  Power 

Low 

Low 

Medium 

High 

Processing  Control 
Automatic  Error 

Low 

Moderately  low 

Medium 

High 

Detection 

Low 

Medium 

Medium 

High 

Decision  Making 

Moderately  low  ! 

Low 

Medium 

High 

Level  of  Degradation 

Low 

Moderately  low 

Medium 

High  „ 

Level  of  Automation  j 

Low 

Moderately  low 

Medium 

High 

Comparison  of  the  four  data  processing  methods  [ 5 ] 
against  fifteen  basic  performance  factors. 


TABLE  II-D . 

Performance  capabilities  are  equally  important  in  the 
consideration  of  a specific  selection.  While  there  are  many 
dimensions  of  data  processing  to  consider,  Burch  and  Strater 
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outline  fifteen  basic  factors.  These  factors  are  compared 
for  each  of  the  previously  identified  methods  of  data  pro- 
cessing in  Table  II-D. 

The  real  deciding  factor  in  the  selection  process, 
however,  may  be  economic.  The  user  could  choose  the  most 
sophisticated  electronic  computer  system  available  to 
accomplish  the  simplest  processing  requirement  if  he  wanted 
to  pay  for  it.  On  the  other  hand,  the  user  might  have  a 
legitimate  requirement  for  that  same  system  based  upon  the 
preceding  criteria  but  be  forced  to  tradeoff  some  of  the 
system's  capabilities  in  light  of  available  resources. 

If  an  electronic  computer  system  is  deemed  appropriate 
for  the  users'  requirements  a further  selection  must  be  made 
among- on-line  processing,  batch  processing,  or  some  combin- 
ation of  the  two.  In  Information  System  Analysis : Theory 

and  Applications , M.  J.  Alexander  presents  three  factors 
pertinent  to  that  decision:  1)  cost,  2)  quality,  and  3) 

timeliness.  Batch  systems  tend  to  be  less  costly  per  trans- 
action because  of  more  continuous  use  of  the  computer  and 
reduced  hardware/software  requirements  as  discussed  in  a 
previous  section.  Alexander  contends  that  batch  systems 
have  fewer  errors  since  it  is  difficult  to  check  on-line 
systems  for  accuracy.  This  evaluation  is  the  basis  for  some 
debate,  as  stated  previously.  On-line  systems  can  provide 
more  current  information  than  batch  systems  due  to  the  basic 
nature  of  the  operation.  If  timeliness  is  crucial  to  the 
operation,  an  on-line  system  is  dictated.  However,  if 
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timeliness  is  not  that  crucial  a batch  system  or  combination 
of  batch  and  on-line  inquiry  as  previously  discussed  are 
viable  options. 

G . SUMMARY 

This  chapter  has  discussed  current  literature  view- 
points in  the  areas  of  planning,  control,  and  MICS.  Con- 
cepts in  the  general  areas  of  system  information  require- 
ments, characteristics,  design  processes,  and  selection 
criteria  were  presented  in  order  to  give  the  reader  a perspec- 
tive from  which  to  examine  and  evaluate  the  MICS  situation 
and  requirements  of  the  SPO/NWC.  The  subsequent  chapters  of 
the  thesis  will  deal  with  application  of  the  Survey,  Require- 
ments, and  Preliminary  Design  Phases  of  the  Rigo  MIS  develop- 
ment model  to  the  SPO/NWC. 


/ 
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III.  CURRENT  SPO/NWC  OPERATION  SURVEY 
A.  BACKGROUND 

The  methodology  adopted  for  this  thesis  research  calls 
for  a survey  phase  to  investigate  the  current  situation 
thoroughly  and  systematically  in  order  to  answer  the  key 
questions  "what  are  the  facts"  and  "what  is  the  real  pro- 
blem?". The  literature  points  out  that  there  are  both 
advantages  and  disadvantages  to  studying  the  existing  sys- 
tems. The  primary  disadvantages  of  analyzing  the  existing 
system  are  that  it  is  expensive  in  terms  of  time  and  re- 
sources, and  that  it  may  introduce  unnecessary  barriers  or 
biases  in  the  development  of  subsequent  systems. 

There  are  four  advantages  in  analyzing  the  present 
system.  First,  the  current  System  may  not  require  replace- 
ment in  total.  Minor  modification  may  result  in  satisfying 
the  information  and  control  needs  of  the  user.  Secondly, 
investigation  of  the  current  system  will  reveal  specific 
areas  which  need  improvement  and  point  out  problem  areas 
which  must  be  dealt  with  if  the  development  of  a new  system 
is  necessary.  Thirdly,  analysis  of  the  current  situation 
will  provide  data  on  the  volume,  sources,  and  character- 
istics of  information  required.  Finally,  analyzing  the 
existing  system  can  provide  an  immediate  source  of  design 
ideas  for  the  new  system.  Dr.  Donald  F.  Heany,  the  author 
of  Development  of  Information  Systems , states  that  "de- 
signers say  they  discover  the  clues  they  need  to  satisfy  the 
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proposed  information  requirement  (during  the  course  of 
analyzing  the  existing  system) . They  do  not  know  how  this 
happens,  merely  that  it  does  happen. "[7] 

For  the  above  reasons,  the  authors  have  chosen  to  study 
the  existing  SPO/NWC  organization  and  the  information  sys- 
tems utilized.  The  investigation  of  the  current  situation 
at  SPO/NWC  is  presented  in  this  chapter  and  entails  discus- 
sion in  the  areas  of  (1)  organizational  relationships,  (2) 
roles  and  responsibilities,  and  (3)  current  management 
information  and  control  systems. 

B.  ORGANIZATIONAL  RELATIONSHIPS 
1.  Naval  Air  Systems  Command 

NAVAIR  is  one  of  six  subordinate  commands  of  the 
Navy  Material  Command.  The  NAVAIR  organization  follows  a 
concept  employing  functional  and  product  organizations  with 
line  and  staff  organizational  structures.  Appendix  A de- 
picts the  NAVAIR  organizational  structure.  In  addition, 
program  management  organizations  are  superimposed  on  the 
basic  functional  organization  for  prosecution  of  selected 
priority  projects.  PMA-259  is  one  of  the  NAVAIR  selected 
priority  projects. 

The  NAVAIR  functional  organization  personnel  are 
used  to  accomplish  the  program  objectives  established  by 
PMA-259.  These  functional  organizations  provide  the  funda- 
mental skills  and  disciplines  required  to  support  the  NAVAIR 
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mission.  These  organizations  are  utilized  by  each  NAVAIR 
program  for  basic  technical  and  administrative  support. 

The  interface  on  the  Sidewinder  Program  between 
NAVAIR  and  NWC  is  PMA-259  and  the  SPO/NWC,  as  these  two 
organizations  have  been  delegated  Sidewinder  Program  respon- 
sibility by  their  respective  commands.  Appendix  B shows  the 
NAVAIR  functional  organizations  which  support  the  Infrared 
Missile  Program  Office  and  their  program  relationship  to 
PMA-259  and  SPO/NWC.  Of  note  is  the  number  and  diversity  of 
functional  disciplines/codes  which  furnish  support  to  PMA- 
259  and  the  fact  that  these  codes  do  not  have  line  responsi- 
bility to  PMA-259. 

2 . Naval  Weapons  Center 

NWC  is  a major  Naval  Laboratory  under  the  direction 
of  the  CNM.  NWC  is  organized  along  functional  lines  and  the 
SPO/NWC  is  located  in  the  Engineering  Design  Division  of  the 
Engineering  Department,  as  illustrated  in  Appendix  C.  It  is 
of  interest  to  note  that  the  relationship  of  the  SPO/NWC  to 
NWC  and  the  Engineering  Department  places  the  SPO/NWC  within 
the  functional  line  organization.  This  type  of  organization 
differs  from  the  clas^_c  matrix  organizational  structure  in 
which  the  SPO/NWC  Manager  would  be  external  to  the  line 
functions  and  would  occupy  a position  within  the  organiza- 
tion at  the  department  or  equivalent  level.  This  more 
conventional  matrix  organizational  relationship  is  illus- 
trated by  the  PMA-259/NAVAIR  organizational  relationship. 
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The  Engineering  Department  at  NWC,  as  depicted  in 
Appendix  D,  is  staffed  and  organized  to  provide  the  techni- 


cal disciplines  required  in  the  acquisition  of  a major 
weapons  system.  The  technical  functions  of  each  division 
are  shown  in  Table  III-A. 

Each  of  the  technical  divisions,  and  particularly 
the  branches  within  each  division,  has  a program  interface 
with  the  SPO/NWC  as  depicted  in  Appendix  E. 

Appendix  E details  the  functional  and  Sidewinder 
program  lines  of  responsibility  and  authority  within  the  NWC 
organization.  As  shown,  the  SPO/NWC  has  program  management 
interface  not  only  with  branches  within  the  Engineering 
Department  but  with  functional  branches  in  other  depart- 
ments. Examination  of  Appendix  E indicates  the  magnitude, 
complexity,  and  diversity  of  the  organizational  relation- 
ships that  exist  between  the  SPO/NWC  and  the  functional 
divisions/branches  which  result  from  the  application  of  the 
program  manager  concept.  As  previously  noted,  the  SPO/NWC 
is  organizationally  located  at  the  branch  level,  and  this 
fact  increases  the  management  planning  and  control  function 
difficulties  inherent  within  a program  manager/functional 
organization  relationship. 

3 . SPO/NWC  Organization 

The  SPO/NWC  is  organized  to  support  the  production, 
development,  test,  and  integrated  logistic  support  (ILS) 
functions  of  the  program.  The  fiscal,  clerical,  business, 
and  data  functions  are  performed  by  a staff  organization  in 
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support  of  the  major  program  functions.  These  relationships 
are  shown  in  the  organizational  chart  of  the  SPO/NWC  as  pre- 
sented in  Appendix  F. 

There  are  sixteen  employees  in  the  SPO/NWC  organi- 
zation. The  fiscal  and  data  functions  are . performed  by 
personnel  who  are  assigned  to  the  office  from  other  func- 
tional codes  on  a full  time  basis.  The  four  functional 
managers  are  supported  by  project  engineers  who  have  respon- 
sibility for  various  components  of  the  missile  system;  i.e.. 
Guidance  and  Control  Section  (GCS) , Active  Optical  Target 
Detector  (AOTD) , etc. 

4 . Participating  Field  Activities  (PFAs) 

The  SPO/NWC  has  program  interfaces  with  other  Navy 
and  Air  Force  activities.  Appendix  G lists  the  primary 
support  activities  with  which  the  SPO/NWC  maintains  an 
interface  and  indicates  the  principal  area  of  support  pro- 
vided by  these  activities.  The  coordination  and  liaison 
with  these  activities  is  required  to  fulfill  the  SPO/NWC 
management  responsibilities  for  which  technical  expertise  is 
not  available  within  NWC  itself. 

5 . Sidewinder  Missile  Component  Contractors 

One  of  the  SPO/NWC  responsibilities  is  to  assist 
NAVAIR  in  the  resolution  of  production  problems.  This  role 
requires  interface  with  companies  who  have  hardware  con- 
tracts for  Sidewinder  components.  Appendix  H lists  the 
major  component  contractors  and  the  components  manufactured, 
with  whom  SPO/NWC  maintains  an  interface. 
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C.  RESPONSIBILITIES/TASKS  AND  INFORMATION  FLOW 

1.  Description  of  Responsibilities  and  Tasks 

The  SPO/NWC  responsibility  is  delegated  to  the 
SPO/NWC  via  the  Commander,  NWC,  through  the  line  organiza- 
tions (see  Appendix  C) . These  responsibilities  flow  from 
two  distinct  sources,  i.e.,  the  program  responsibilities  as 
defined  in  AIRTASKS  and  Work  Unit  Assignments  and  the  NWC 
organization  responsibilities  as  defined  in  NWC  and  Engi- 
neering Department  instructions  and  policies .[ 8&9 ] 

The  SPO/NWC  Manager,  as  head  of  the  SPO/NWC,  oper- 
ates under  the  Sidewinder  (AIM-9)  Program  Management  Plan. 
The  responsibilities  as  defined  in  the  plan  are:  a)  The 

overall  missile  system  coordination  function  between  NAVAIR 
sponsoring  activities/co-sponsoring  USAF  activities/foreign 
country  users  and  NWC,  b)  the  overall  missile  system  coor- 
dination function  (as  delegated  by  NAVAIR  between  the  sup- 
porting field  activities  and  NWC,  c)  the  overall  missile 
system  coordination  function  (as  delegated  by  NAVAIR  between 
the  primary  and/or  secondary  source  contractors  for  missile 
system  hardware  and  NWC,  d)  the  overall  missile  system 
coordination  function  between  NWC  supporting  contractors  or 
field  activities  and  NWC,  and  e)  the  overall  missile  system 
coordination  function  between  the  SPO/NWC  and  the  NWC  sup- 
porting/participating codes. 

To  carry  out  his  assigned  responsibilities,  the 
SPO/NWC  Manager  performs  or  directs  the  performance  of  the 
following:  a)  establishment,  structuring,  and  supervision 
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of  the  SPO/NWC  to  carry  out  its  assigned/delegated  func- 
tions, b)  acquisition  and/or  assignment  of  SPO/NWC  staff 
members  to  perform  assigned  tasks  in  accordance  with  the 
established  organizational  and  functional  charts,  c)  estab- 
lishment of  policy  and  procedure  guidelines  for  carrying  out 
these  assigned/delegated  functions,  d)  preparation  and/or 
implementation  of  task  assignments  to  be  performed  together 
with  the  responsibility  and  authority  assigned  (including 
the  determination  of  the  in-house/off-Center  structure) , e) 
establishment  and/or  implementation  of  planning  and  control 
procedures  for  monitoring  the  progress  of  accomplishments, 
f)  establishment  and/or  implementation  of  reporting  proce- 
dures as  required  for  off-Center  sponsoring  activities  and 
NWC , g)  preparation  and  presentation  of  program  material/ 
briefings  for  off-Center  sponsors  and  other  Department  of 
Defense  official  visitors,  and  h)  establishment  and  mainte- 
nance of  a permanent  file  for  all  program  related  informa- 
tion. 

In  summary,  the  basic  responsibility  of  the  SPO/NWC 
Manager  is  one  of  managing  an  organization  with  policies , 
planning  and  control  techniques  to  perform  the  tasks/func- 
tions required  to  support  the  Sidewinder  Program. 

As  shown  in  Appendix  F,  the  SPO/NWC  is  organized  to 
support  the  functional  requirements  of  the  AIM-9  series 
missile,  i.e.,  development,  test,  ILS , and  production. 

Using  the  SPO/NWC  organization  as  the  basis,  Figure  III-l 
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depicts  the  decision  levels  used  by  the  SPO/NWC  Manager  to 
fulfill  the  assigned  responsibilities. 


ORGANIZATION 

RESPONSIBILITY 

PROGRAM  MANAGER 

POLICY  AND  PROCEDURE  GUIDELINES 

PRODUCTION  MANAGER 

POLICY  AND  PROCEDURE  IMPLEMENTATION 

PROJECT  ENGINEERS: 

O GCS 
O AOTD 

OAFT  COMPONENTS 
O EXPLOSIVE  COMPONENTS 

OPERATIONAL 

DECISION  LEVEL  DIAGRAM-SPO/NWC 
FIGURE  III-l 


Figures  III-2,  III-3,  and  III-4  are  functional 
charts  which  depict  the  functional  areas,  elements,  and 
items  for  which  the  Production  Manager  has  been  delegated 
responsibility.  The  Production  Manager  has  the  responsibil- 
ity to  coordinate  with  each  Project  Engineer  to  ensure  that 
the  production  engineering,  production  monitoring,  and 
fiscal  accountability  areas  are  addressed  within  the  Project 
Engineer's  areas  of  responsibility.  The  Project  Engineers 
have  the  responsibility  for  one  or  a series  of  missile 
components  as  illustrated  in  Figure  III-l.  Each  Project 
Engineer  is  responsible  for  accomplishment  of  all  tasks 
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relating  to  his  missile  components  in  each  of  the  functional 
areas  of  production  monitoring  and  production  engineering. 

The  budget,  funding,  and  cost  control/reporting 
elements,  as  shown  on  Figure  III-4,  are  accomplished  through 
a series  of  procedures  performed  by  SPO/NWC  staff  personnel. 
However,  the  Project  Engineers  have  the  responsibility  of 
monitoring  actual  costs  versus  planned  expenditures.  The 
primary  responsibility  of  the  production  manager  in  the  area 
of  fiscal  accountability  is  the  establishment  of  job  orders 
(JOs)  under  NWC  fiscal  guidelines. 

The  SPO/NWC  AIM-9L  production  support  responsibili- 
ties are  defined  through  the  AIRTASKS  and  Work  Unit  Assign- 
ments presented  in  Appendix  I.  These  responsibilities  are 
outlined  in  very  general  terms.  Specific  tasks  are  identi- 
fied on  an  "as  required"  basis  to  support  a specific  con- 
tract. A similar  situation  exists  with  the  SPO/NWC  person- 
nel's responsibilities , i.e.,  responsibilities  are  defined 
in  general  terms  in  personnel  descriptions  and  through 
organization  charts.  Detailed  tasks  are  assigned  on  an  "as 
required"  basis. 

2 . Assignment  of  Tasks  and  Information  Flow 

To  this  point,  the  discussion  of  the  SPO/NWC  opera- 
tion has  highlighted  the  organizational  relationship,  func- 
tions, and  responsibilities  of  the  organization  and  person- 
nel in  the  AIM-9L  production  support  effort.  This  section 
will  identify  how  the  previously  mentioned  detail  tasks  are 
received  and  assigned,  the  nature  of  these  detail  tasks,  and 
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what  kind  of  information  requirements,  characteristics,  and 
interfaces  are  associated  with  these  tasks. 

The  detailed  tasks  received  by  the  SPO/NWC  are  as 
numerous  and  diverse  as  the  previous  discussions  would 
indicate.  They  are  received  from  any  and  all  organizations 
discussed  previously  and  take  the  form  of  phone  calls, 
messages,  letters,  etc.  In  order  to  quantify  the  volume  and 
form  of  these  requests  for  task  accomplishments,  the  authors 
collected  data  from  correspondence  files.  In  addition,  the 
SPO/NWC  Manager,  the  Production  Manager  and  the  GCS  Project 
Engineer  maintained  logs  of  incoming  requests  for  a period 
of  twenty  working  days.  The  raw  data  and  assumptions  used 
to  arrive  at  the  volume  and  type  data  shown  in  Table  III-B 
are  contained  in  Appendix  J.  The  data  presented  in  Table 
III-B  illustrates  the  volume,  data  form  and  organizational 

level  of  the  information  flow.  This  data  will  be  used  to 

I 

assess  the  needed  MICS  characteristics  and  capabilities  in 
the  next  chapter. 

The  characteristics  of  information  received  by  each 
member  of  the  office  to  fulfill  his  responsibilities  is 
different.  The  difference  is  primarily  in  the  level  of  ' 

detail  and  scope  of  information  required  for  the  decision 
making  process,  i.e.,  the  Project  Engineer  is  involved  with 
many  detail  facts  on  one  component  of  the  Sidewinder  mis- 
sile, the  Production  Manager  is  involved  with  production 
problems  encompassing  all  the  components  of  the  Sidewinder 
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missile,  the  SPO/NWC  Manager  is  involved  with  summarized 
facts  for  all  functions  of  the  program. 

The  flow  of  information  (who  receives/who  requests) 
is  also  different.  The  Project  Engineers'  primary  contacts 
are  with  the  NAVAIR  technical  codes,  contractor  technical 
engineers,  and  NWC  technical  personnel  and  production  mana- 
gers. The  Production  Manager's  primary  contacts  are  with 
the  NAVAIR  Assistant  Project  Manager,  NWC  branch  heads,  and 
contractor  program  personnel.  The  SPO/NWC  Manager's  primary 
contacts  are  the  NAVAIR  Project  Manager,  other  DoD  Program 
personnel,  NWC  division  and  department  heads. 

Figure  III-5  represents  an  information  flow  anal- 
ysis from  and  to  the  SPO/NWC.  For  purposes  of  this  study, 
only  one  Project  Engineer  is  addressed.  The  other  Project 
Engineers  would  have  similar  interfaces  with  applicable 
NAVAIR  and  NWC  technical  codes.  The  type  and  content  of 
tasks  and  information  flow  for  other  Project  Engineers  would 
be  similar.  The  different  individuals  and  organizations 
that  interface  with  the  SPO/NWC  personnel  are  noted.  The 
solid  and  dash  lines  represent  information  flow  into  and  out 
of  the  SPO/NWC,  respectively.  This  analysis  is  helpful  in 
showing  the  multiple  informational  interfaces  at  each  level 
and  the  multidimensional  aspects  of  the  information  flow. 

The  assignment  of  tasks  within  the  SPO/NWC  organi- 
zation can  be  described  as  a structured  or  programmed 
decision-making  process.  The  requests  for  task  accomplish- 
ment are  directed  to  the  cognizant  functional  area  and/or 


INFORMATION  FLOW  INTO  SPO/NWC 

■+ INFORMATION  FLOW  OUT  OF  SPO/NWC 

A.  ENGR  DESIGN  DIVISION  HEAD 
8 SPO/NWC  MANAGER 

C.  PRODUCTION  MANAGER 

D.  PROJECT  ENGINEER  IGCS) 

E.  INFRARED  MISSILE  PROGRAM  MANAGER 
F GCS  TECHNICAL  ENGINEER  (NAVAIR) 

G.  RAYTHEON  COMPANY 
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I.  NWC  SUPPORT  CONTRACTOR 
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V MECH  AND  SPECIAL  EQUIP  INWC) 

W SYSTEMS  ELEC  (NWC) 


INFORMATION  FLOW  DIAGRAM 
FIGURE  ID-5 


73 


Project  Engineer  by  the  application  of  a predetermined  area 
of  responsibility  guide.  Distribution  of  incoming  corre- 
spondence is  made  from  a standard  distribution  list  which 
relates  subject  to  cognizant  personnel,  i.e.,  the  Project 
Engineer  (GCG)  receives  a copy  of  all  correspondence  relat- 
ing to  the  GCG,  the  Production  Manager  receives  a copy  of 
all  production  related  items,  and  the  SPO/NWC  Manager  re- 
ceives a copy  of  all  correspondence.  The  Data/Configuration 
Manager  (D/CM)  receives  all  correspondence  related  to  data 
(ECPs,  contract  data  items,  etc.)  It  is  then  the  responsi- 
bility of  each  individual  to  take  action  on  items  (tasks) 
relating  to  their  area  of  responsibility. 

Examples  of  the  process  would  be:  1)  the  D/CM 

receives  all  ECPs  and  starts  them  into  the  configuration 
control  process,  and  2)  the  Project  Engineer  receives  a 
request  for  a specific  task  accomplishment  and  then  proces- 
ses action  items  by  a formal  task  agreement  or  verbal  ar- 
rangement with  the  functional  codes,  depending  on  funding 
requirements  and  scheduled  time  span.  It  is  significant  to 
note  that  the  programmed  method  of  task  assignment  within 
the  SPO/NWC  does  not  record  these  specific  arrangements  in 
any  formal  system.  Sometimes  a "tickler"  copy  of  an  action 
document  which  has  been  assigned  to  a particular  Project 
Engineer  is  retained,  or  a note  is  made  in  the  SPO/NWC 
Manager's  notebook,  but  no  formal  record  is  kept  on  all 
assignments.  Formal  systems  do  exist  to  control  and  track 
certain  items,  such  as  ECPs  and  contract  data  items.  These 
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systems  will  be  discussed  in  the  following  section  of  the 
thesis . 


The  assignment  of  tasks  by  the  SPO/NWC  personnel  to 
the  NWC  functional  organization  is  accomplished  through  a 
task  agreement  system  as  indicated  above.  Each  functional 
code  which  supports  the  SPO/NWC  is  issued  a task  agreement 
which  defines  the  scope  of  work,  funding  required,  and 
schedule  anticipated  for  a given  fiscal  year.  The  Produc- 
tion Manager,  Project  Engineer,  and  SPO/NWC  Manager  as  a 
team  write  these  task  agreements  as  a part  of  the  yearly 
budget  process.  Task  assignments  are  made  within  these  task 
agreements  in  response  to  specific  requests  for  work  or 
information  received  by  the  SPO/NWC.  The  major  tasks  of  the 
Project  Engineer  are  to  determine  the  progress  of  specific 
detail  tasks  against  a general  task  agreement  and  meet 
program  commitments.  The  Project  Engineer  has  the  responsi- 
bility to  monitor  the  task  progress  on  a continuing  basis 
through  personal  contact  and  weekly  fiscal  reports.  Addi- 
tional task  agreements  are  written  for  special  efforts  not 
anticipated  at  the  start  of  the  fiscal  year,  and  where  the 
funding  requirement  is  greater  than  twenty-five  thousand 
dollars.  All  these  task  agreements  are  in  essence  a formal 
contract  between  the  SPO/NWC  and  each  of  the  functional 
codes.  Information  flow  among  all  the  participants,  as 
shown  in  Figure  III-5,  takes  many  forms.  In  addition  to  the 
"as  required"  communication  flows  previously  discussed, 
there  exists  a requirement  for  formal  periodic  reports  to 
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NAVAIR  and  NWC  management  from  the  SPO/NWC.  These  reports 
are  to  provide  the  overall  program  progress  in  terms  of 
cost,  schedule,  and  performance  which  is  required  for  man- 
agement decision  making.  A detailed  discussion  of  these 
reports  and  the  system  for  their  generation  will  be  under- 
taken in  the  next  section. 

D.  CURRENT  CONTROL  AND  INFORMATION  SYSTEMS 

A single  integrated  MICS  does  not  currently  exist 
within  the  SPO/NWC.  Rather,  the  existing  system  is  made  up 
of  a number  of  disjointed  systems  designed  to  perform  infor- 
mation and  control  functions  in  specific  areas.  These 
systems  include  the  Correspondence  Filing  and  Distribution 
System,  Funding  Control  System,  Task  Agreement  System,  Mark 
III  Management  System,  Data/Configuration  Management  System, 
Periodic  Reports  System,  and  Program  Review  Action  Item 
system.  This  section  will  discuss  each  of  these  systems 
individually  to  gain  an  appreciation  for  their  purpose, 
functions  and  effectiveness. 

1.  Correspondence,  Filing  and  Distribution 

The  correspondence  and  filing  system  in  the  SPO/NWC 
is  designed  to  log,  distribute  and  file  each  item  of  corre- 
spondence which  is  transmitted  from  or  received  by  the 
office.  Correspondence  as  used  herein  is  either  a letter, 
message,  transmittal  receipt,  speedletter  or  memorandum. 

The  system  functions  are  performed  by  a civilian  contractor 


and  utilizes  the  contractor  person  fulltime.  The  annual 
cost  to  the  SPO/NWC  is  $24,000. 


Figure  III-6  depicts  the  steps  which  each  item  of 
correspondence  follows  through  the  system.  The  log  entries 
and  semi-annual  listing  contain  the  microfilm  ID  numbe-r, 
the  date  of  the  document,  the  type  of  correspondence,  the 
originator  file  number,  the  originator's  code  or  organiza- 
tion, the  correspondence  serial  or  registration  number,  the 
addressee  name  or  code,  the  subject  of  the  correspondence, 
and  the  title  of  any  enclosures.  Approximately  a one  day 
turn-around  time  is  involved  in  the  distribution,  microfilm 
and  file  processes.  The  keypunching  is  not  done  on  a 
regular  basis.  The  sorting  of  the  card  deck  file  and  pro- 
duction of  the  file  number  sequence  listing  is  done  semi- 
annually. The  file  copy  is  maintained  in  the  SPO/NWC  files 
for  two  years;  after  this  time  it  is  packaged,  transferred 
to  a federal  storage  facility,  and  stored  indefinitely.  The 
developing  of  the  microfilm  is  done  monthly  and  the  micro- 
film cartridges  are  retained  in  the  SPO/NWC. 

The  system  is  basically  designed  to  provide  a 
permanent  record  of  all  SPO/NWC  correspondence.  With  the 
date  and  originator,  any  item  of  correspondence  can  be 
retrieved  from  the  file  system. 

2 . Funding  Control  Process 

The  description  of  the  funding  control  process  is 
limited  to  the  interaction  of  the  SPO/NWC  and  the  NWC 
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CORRESPONDENCE  FILING  AND  DISTRIBUTION  SYSTEM  FLOW  DIAGRAM 

FIGURE  m-6 


Comptroller  (Code  08)  financial  system  and  therefore  does 
not  include  the  Code  08  processing  procedures.  The  SPO/NWC 
budget  as  submitted  to  PMA-259  (sponsor)  is  the  basis  for 
the  funding  received  by  NWC  for  the  Sidewinder  production 
support  effort. 

The  funding  system,  as  depicted  in  Figure  III-7,  is 
used  to  report,  bill,  and  track  the  funding  from  sponsors 
for  all  NWC  projects  and  programs.  The  SPO/NWC  production 
support  funding  is  identified  through  the  NWC  financial 
system  by  a seven  digit  customer  order  number.  The  customer 
order  identifies  the  funds  to  the  Engineering  Department, 
the  Sidewinder  production  support  effort,  and  the  fiscal 
year  the  funding  was  appropriated.  Added  to  the  customer 
order  are  three  letters  which  define  the  job  order  (JO) . 
Unique  JO  letters  are  established  by  the  SPO/NWC  Production 
Manager  for  each  task  agreement  entered  into  with  the  func- 
tional codes.  The  JO  letters  are  the  means  by  which  the 
SPO/NWC  identify,  track,  and  control  the  internal  expendi- 
tures versus  task  agreement  allocations. 

As  noted  in  Figure  III-7,  there  are  two  processes 
involved;  one  is  the  NWC  Code  08  financial  system,  which  has 
the  control  of  all  financial  processing  and  two,  the  SPO/NWC 
JO  system  which  establishes  the  JO  and  task  agreement  from 
which  the  functional  codes  derive  the  assets  to  pay  sal- 
aries, purchase  material,  etc. 

Funding  documents,  i.e.,  AIRTASK,  MIPR,  etc.,  are 
received  by  Code  08  and  enter  the  financial  system.  Then 
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SPO/NWC , Engineering  Design  Division,  and  Engineering  Depart- 
ment review  the  documents  for  acceptance  or  rejection.  Once 
the  funding  is  accepted,  a planned  budget  with  JOs  is  submit- 
ted to  Code  08.  This  budget  establishes  the  planning  data 
required  by  NWC  management  for  the  funds  received.  The 
budgets  are  prepared  by  the  Production  Manager  and  Project 
Engineers  based  on  projected  task  inputs  from  each  of  the 
functional  codes  involved  in  the  particular  task  agreement. 
Format,  overall  policy  and  content  are  reviewed  by  the 
SPO/NWC  financial  assistant  and  SPO/NWC  Manager  before 
release.  The  budget  documents  are  also  signed  by  the  divi- 
sion and  department  offices. 

Once  the  funding  documents  are  received,  approved, 
and  budgets  prepared,  the  functional  codes  can  use  the 
funding  for  the  performance  of  specific  tasks.  As  task 
assignments  are  accomplished  by  the  functional  codes,  the 
applicable  customer  order  and  JO  are  cited  on  timecards , 
requisitions,  and  other  expenditure  documents.  The  SPO/NWC 
is  not  involved  in  the  functional  codes  timecard  payroll 
process  but  does  approve  all  other  expenditure  documents. 

Once  the  charges  are  made  against  the  particular 
customer  order  and  JO,  a report  is  generated  which  details 
all  charges.  This  report  is  received  on  a weekly  basis  and 
is  used  by  Project  Engineers  and  Proauction  Manager  to  track 
funds  expended  against  various  task  agreements.  The  monthly 
summary  is  used  by  the  SPO/NWC  Manager  to  track  expenditures 
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against  budgeted  amounts.  The  monthly  summary  is  also  sent 
to  PMA-259  as  a portion  of  the  SPO/NWC  monthly  report. 

3 . Task  Agreement  Process 

The  SPO/NWC  depends  on  the  functional  organization 
for  the  support  necessary  to  fulfill  the  Sidewinder  AIM-9 
responsibility  at  NWC.  To  define  the  support  requirements 
between  the  SPO/NWC  and  the  functional  codes , formal  task 
agreements  are  established.  The  task  agreements  are  the 
principal  formal  program  link  between  the  SPO/NWC  and  the 
functional  code. 

The  task  agreements  are  typically  general  in  nature 
and  define  the  description  of  work,  the  approach  to  be 
taken,  and  the  estimated  funding  by  customer  order  and 
unique  JO.  Appendix  K is  an  example  of  a typical  task 
agreement.  As  seen  in  the  example,  the  approach  is  general 
and  the  period  of  performance  (schedule)  is  continuing  for 
one  year. 

The  task  agreements  usually  are  established  on  the 
fiscal  year  and  follow  the  budget  cycle,  although  task 
agreements  are  established  for  special  tasks  when  the  esti- 
mated cost  is  over  twenty-five  thousand  dollars. 

Any  particular  detail  tasks  then  remain  to  be 
defined  and  assigned  in  meetings,  memoranda  or  telephone 
calls  between  the  Project  Engineers  and  the  functional 
organization. 

In  summary,  the  task  agreements  perform  the  fol- 
lowing functions:  a)  define  the  general  resource  level 
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required  from  the  functional  code,  b)  define  the  general 
description  of  work  and  approach,  c)  define  the  funding 
level  for  the  functional  organization  with  unique  JOs , d) 
define  the  reporting  requirements,  and  e)  define  the  general 
schedule . 

4 . Mark  III  Management  System. 

The  Mark  III  Management  system  is  used  within  the 
SPO/NWC  to  visually  display  the  Sidewinder  component  con- 
tracts' Master  Data  Program  Schedules.  The  Mark  III  Manage- 
ment system  is  a computer  based  management  system  with  two 
basic  outputs  available  to  the  user:  1)  direct  outputs  from 

the  computer,  and  2)  outputs  resulting  from  computer  gener- 
ated plots. 

The  direct  outputs,  i.e,  listing  of  planning 
updates,  listing  of  safety  paths,  etc.,  are  not  used  in  the 
Sidewinder  Production  Support  effort  and  will  not  be  dis- 
cussed. The  computer  generated  plot  is  used  for  tracking 
contract  data  items  (CDI)  in  the  AIM-9L  Production  Support 
area.  Contract  data  items  are  primarily  reports  and  plans 
required  to  be  delivered  by  the  contractor  at  prescribed 
times  or  intervals  in  accordance  with  the  contract.  These 
reports  and  plans  (referred  to  as  contract  data  items)  are 
reviewed  by  NWC  to  insure  compliance  with  the  contract  and 
technical  worth. 

The  computer  generated  plot  is  basically  a planned 
schedule.  The  plots  are  available  in  three  different  forms: 
1)  detail,  2)  selective,  and  3)  summarization.  For  contract 
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data  items,  the  summarization  form  is  used.  The  plots,  one 
for  each  contract,  give  the  activity  (data  item) , respon- 
sible Project  Engineer,  and  item  delivery  schedule  for  each 
data  item.  Figure  III-8  is  a block  diagram  of  the  flow  of 
a data  item  when  received  by  the  SPO/NWC. 

The  data  plots  are  used  as  a visual  representation 
of  the  contract  data  item  delivery  dates.  The  incoming 

V 

contract  data  items  are  checked  against  the  contract  re- 

\ 

quirements  by  a data  clerk,  and  are  routed  to  functional 
codes  with  a response  date  assigned  by  the  Data  Manager  and 
Project  Engineer.  The  data  clerk  tracks  the  response  dates 
and  compiles  review  notes.  The  Data  Manager  and/or  Project 
Engineer  then  write  a letter  response  as  required  in  the 
specific  contract. 

5 . Data/Conf iquration  Management  System 

The  configuration  management  responsibility  within 
the  SPO/NWC  requires  evaluation  of  Engineering  Change  Pro- 
posals (ECPs ) , establishment  of  product  baselines,  establish- 
ment and  maintenance  of  a master  documentation  control 
center,  and  establishment  of  configuration  management  prac- 
tices . 

Plans  to  define  data/configuration  management 
practices  and  policies  within  NWC  are  contained  in  the 
Document  Control  Plan  for  the  Sidewinder  AIM-9H/L  missile 
(TN  5551-1-75).  The  bulk  of  the  configuration  management 
effort  is  in  the  processing  of  ECPs  required  to  control, 
change,  and  maintain  the  product  baseline.  The  product 
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baseline  includes  all  drawings  and  specifications  used  to 
define  the  AIM-9L  missile.  To  illustrate  the  process  in- 
volved in  changing  the  product  baseline,  a flow  diagram,  which 
includes  the  contractor  and  Defense  Contract  Administration 
Service  (DCAS)  organization ' s role  along  with  process  time 
requirements,  is  shown  in  Appendix  L.  As  illustrated, 
twenty  steps  are  performed  by  the  SPO/NWC  Project  Engineer, 
D/CM,  Configuration  Accounting  personnel  and  appropriate 
functional  codes  upon  receipt  of  an  ECP  by  the  SPO/NWC. 

These  actions  require  about  20  working  days  to  accomplish. 

The  SPO/NWC  receives  anywhere  from  20  to  50  Class  II  ECPs  a 
month  which  are  processed  within  the  SPO/NWC  by  the  D/CM  and 
two  data  clerks. 

Processes  similar  to  those  shown  in  Appendix  L 
are  required  for  a Class  I ECP  with  the  exception  that 
NAVAIR  has  final  approval/  disapproval  authority.  Once 
production  deliveries  have  started;  however,  only  four  to 
five  Class  I ECPs  are  received  each  month  so  they  have  a 
small  impact  on  the  overall  workload. 

6 . Periodic  Reports 

There  are  four  formal  periodic  reports  required 
from  the  SPO/NWC  in  conjunction  with  the  AIM-9L  Production 
Support  effort.  The  NAVAIR  program  status  report  and  the 
visit  action  report  are  each  required  on  a monthly  basis. 
Reports  to  NWC  management  consist  of  the  NWC  Management 
Program  Status  Report  (monthly) , and  the  NWC  Weekly  Program 
Highlight  Report. 
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The  monthly  NAVAIR  report,  the  most  comprehensive 
of  the  reports,  includes  a detailed  technical  status  of  each 
functional- discipline  of  -the  p-ro-gram  with- c-o-r respond in-g-  - - — 
funding  status.  The  technical  status  is  compiled  by  the 
Project  Engineer  from  monthly  reports  submitted  by  the 
functional  codes.  The  funding  status  is  compiled  from  the 
detail  Code  08  computer  summary.  The  monthly  status  reports 
submitted  by  the  technical  codes  are  received  by  the  SPO/NWC 
ten  days  after  the  end  of  the  report  month.  The  Project 
Engineers  then  integrate  these  reports  and  submit  the  draft 
NAVAIR  report  to  the  SPO/NWC  Manager.  The  report  is  nor- 
mally mailed  to  NAVAIR  by  the  end  of  the  month  following  the 
report  month. 

The  NAVAIR  visit  action  reports  are  used  to  provide 
information  to  NAVAIR  on  NWC  personnel's  trips  to  missile 
component  manufacturers'  facilities.  There  are  an  average 
of  twenty  visit  action  reports  prepared  per  month.  The 
reports  are  prepared  by  the  traveler,  collected  by  the 
SPO/NWC  and  transmitted  to  PMA-259  by  official  letter. 

The  NWC  internal  management  reports  are  prepared  by 
the  Production  Manager  and  Project  Engineers.  The  funding 
data  is  summarized  from  the  same  data  as  the  NAVAIR  reports 
and  the  technical  aspects  are  short  comments  on  significant 
problems  and/or  accomplishments,  prepared  by  the  Production 
Manager  and  Project  Engineers,  with  less  detail  than  the 
NAVAIR  reports.  The  NWC  internal  management  reports  are  of 
two  types:  1)  a NWC  Commander's  report  prepared  on  a monthly 
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basis,  and  2)  an  Engineering  Department  Head  (Highlight) 
report  prepared  on  a weekly  basis.  The  Highlight  report 
contains  more  technical  progress  and  problem  details  and 
does  not  contain  funding  data. 

7 . Program  Review  Action  Items 

Formal  program  reviews  between  Navy  and  component 
contractors  personnel  are  held  on  a periodic  basis.  The 
reviews  are  program  production  related  with  program  status 
and  problems  the  primary  agenda.  The  results  of  these 
reviews  are  formal  and  semi- formal  minutes  with  action  items 
assigned  by  the  Infrared  Missiles  Program  Manager  or  Assist- 
ant Program  Manager  (APM)  to  the  contractor,  NAVAIR  func- 
tional personnel  and/or  NWC . The  SPO/NWC  has  the  responsi- 
bility to  see  action  is  taken  on  all  items  assigned  to  NWC. 

The  process  followed  to  ensure  action  item  accom- 
plishment depends  on  the  responsible  Project  Engineer  and 
the  priorities  he  assigns  to  program  review  action  items, 
the  type  of  personnel  available  within  the  functional  codes 
to  respond  to  his  requests,  his  ability  to  persuade  the 
functional  personnel,  etc.  There  is  no  formal  process 
established  and  each  Project  Engineer  uses  his  own  system  to 
assign,  track  and  report  status  of  program  review  action 
items . 

The  volume  of  action  items  resulting  from  any  given 
status  review  meeting  is  highly  variable.  For  example,  the 
number  of  action  items  from  two  consecutive  GCS  contract 
status  review  meetings  was  from  four  to  sixty-two.  With  an 
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average  of  one  status  review  meeting  per  month,  this  would 
be  an  average  of  thirty-three  action  items  SPO/NWC  Project 
Engineers  must  delegate  to  functional  codes,  track  and 
report  status  on  per  month. 
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IV.  SIDEWINDER  PROGRAM  OFFICE  (NWC)  MICS  REQUIREMENTS 
A.  BACKGROUND 

To  this  point,  the  authors  have  stated  the  problem  of 
program  planning  and  control  as  it  exists  at  the  SPO/NWC. 

The  problem  has  been  presented  in  general  terms  and  with 
current  literature  viewpoints  on  the  managerial  functions  of 
planning  and  control  and  MICS  considerations.  In  addition, 
they  have  detailed  the  current  environment  of  the  SPO/NWC, 
and  the  systems  currently  used  to  provide  information  for 
planning  and  control  purposes.  The  previous  chapters, 
therefore,  represent  the  first  two  phases  of  the  MICS  system 
life  cycle  as  presented  in  Chapter  I.  This  chapter  will 
address  the  elements  of  the  third  phase  in  the  life  cycle  - 
the  Requirements  Phase.  The  roles,  responsibilities  and 
information  flows  described  in  Chapter  III  will  be  consid- 
ered in  terms  of  concepts  and  considerations  presented  in 
Chapter  II  in  order  to  arrive  at  meaningful  system  require- 
ments for  a MICS  to  support  the  needs  of  SPO/NWC.  The 
information  and  control  systems  currently  in  existence  at 
SPO/NWC  will  be  evaluated  in  light  of  these  systems  require- 
ments in  order  to  determine  the  adequacy  of  their  perform- 
ance. The  result  of  this  review  and  evaluation  process  will 
be  a gross  MICS  design  for  the  SPO/NWC. 

This  requirements  determination  activity,  as  outlined 
by  Rigo,  is  nothing  more  than  the  design  process  as  discus- 
sed in  Chapter  II.  As  previously  presented  in  that  chapter. 
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Dr.  Wilkinson  contends  that  the  appropriate  design  process 
is  dictated  by  the  perspective  taken  with  respect  to  the 
MICS.  The  authors  contend  that  the  appropriate  perspective 
for  the  SPO/NWC  MICS  is  that  of  a decision-oriented  network 
and  therefore  the  appropriate  design  approach  is  one  of 
defining  the  required  outputs  and  working  backwards  to 
specify  the  input  data  and  conversion  processes  necessary. 
This  contention  is  made  based  upon  the  assumption  that  the 
information  needed  within  the  SPO/NWC  for  the  successful 
accomplishment  of  the  majority  of  their  responsibilities  can 
be  provided  by  regularly  scheduled  reports.  This  basic 
assumption  will  be  verified  as  the  requirements  determina- 
tion/design process  is  executed  in  this  chapter,  with  the 
exception  of  specific  instances  which  will  be  indicated. 

In  executing  the  design  process  in  this  chapter  the 
authors  will  use  a modified  Burch  and  Strater  approach.  The 
initial  effort  will  be  the  definition  of  the  desired  SPO/NWC 
MICS  goals  and  objectives.  The  current  systems  will  be 
evaluated  in  terms  of  their  ability  to  meet  these  goals  and 
objectives.  This  will  be  followed  by  the  development  of  a 
conceptual  model  of  the  desired  system  and  the  definition  of 
required  outputs.  Finally,  the  necessary  inputs  and  proces- 
sing will  be  addressed. 

B.  SPO/NWC  MICS  GOALS  AND  OBJECTIVES 

It  can  be  seen  that  the  roles  and  responsibilities  of 
the  personnel  within  the  SPO/NWC,  as  described  in  Chapter 
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Ill,  fall  into  the  categories  of  operational  control  and 
managerial  control  in  the  Anthony  framework.  The  Project 
Engineers  are  responsible  for  assuring  that  specific  tasks 
are  carried  out  within  their  areas  of  cognizance.  The 
Production  Manager  and  the  SPO/NWC  must  coordinate  and  plan 
to  assure  that  resources  are  obtained  and  used  effectively 
and  efficiently  in  the  accomplishment  of  the  program  objec- 
tives. In  general,  it  can  be  stated  that  the  goals  of  the 
SPO/NWC  MICS  are  to  provide  operational  control  at  the 
Project  Engineer  level,  and  managerial  control  at  the  Pro- 
duction Manager  and  SPO/NWC  Manager  level.  The  adoption  of 
this  perspective  allows,  perhaps  even  requires,  the  use  of 
the  information  and  MICS  characteristics  and  considerations 
appropriate  to  these  categories  in  the  design  process  of  the 
SPO/NWC  MICS.  Within  these  two  general  MICS  goals  of  oper- 
ational and  managerial  control  are  various  objectives  which 
will  be  discussed  in  the  following  sections. 

1 . Operational  Control 

The  first  objective  of  the  operational  control 
aspect  of  the  MICS  is  to  provide  a "closed-loop"  task  track- 
ing system.  Koontz  and  O'Donnell  state  that  "the  basic 
control  process,  wherever  it  is  found  and  whatever  it  con- 
trols, involves  three  steps:  1)  establishing  standards,  2) 

measuring  performance  against  these  standards,  and  3)  cor- 
recting deviations  from  standards  and  plans. "[10]  This  de- 
scription implies  a "closed- loop"  system  whereby  information 
is  fed  back  to  the  manager  in  order  for  him  to  measure 


92 


1 


1 


actual  : < rma  staclished  standards.  The 

object  • • • : i • -ystem  is  to  provide  a mech- 
anism r :.:.a  as r. s to  be  accomplished,  and  a 

means  of  . ion:  . : . : • t asks  which  have  been  completed 

and  those  which  have  ncr  in  order  for  the  Project  Engineer 
to  take  appropriate  action. 

A second  objective  of  the  operational  control 
subsystem  is  to  provide  a uniform  or  standardized  method  and 
format  for  the  tracking  of  tasks  within  the  SPO/NWC  organi- 
zation. One  of  the  problems  described  in  Chapter  I was  the 
lack  of  uniformity  among  the  individual  Project  Engineers' 
methods  of  task  tracking  which  results  in  considerable 
confusion  and  research  effort  when  these  individuals  are 
absent  or  rotated.  The  establishment  of  a single  format  or 
method  would  allow  for  timely  and  orderly  retrieval  of 
information  in  the  absence  of  any  particular' individual  and 
allow  for  reduced  training  among  Project  Engineers  in  the 
event  of  position  rotation. 

A third  objective  of  the  operational  control  sub- 
system is  funding  visibility  at  the  JO  level.  In  addition 
to  monitoring  task  accomplishment  in  terms  of  schedule  and 
performance,  the  Project  Engineers  should  be  able  to  track 
expenditures  on  tasks  being  performed  within  the  functional 
codes  and  PFAs  as  appropriate. 

A final  objective  of  the  operational  control  por- 
tion of  the  MICS  is  the  ability  to  provide  operational 
information  for  historical  purposes.  One  of  the  elements  of 
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the  first  operational  control  objective  (closed-loop  task 
tracking)  was  the  identification  of  the  actual  accomplish- 
ment of  an  assigned  task.  While  the  primary  use  of  this 
information  is  to  highlight  the  remainder  of  the  tasks, 
i.e.,  to  identify  those  tasks  which  have  not  been  completed, 
an  equally  important  aspect  is  the  ability  to  produce  proof 
of  task  accomplishment  and  provide  the  informational  results 
of  the  task  completion  at  some  point  in  the  future.  The 
MICS  must  include  this  capability  in  order  to  adequately 
support  the  SPO/NWC  operations . 

2 . Managerial  Control 

In  order  to  exercise  effective  managerial  control, 
the  decision  maker  must  have  visibility  into  the  resource 
areas  which  he  is  attempting  to  manage.  The  first  objective 
of  the  managerial  control  subsystem  of  the  MICS  is  to  pro- 
vide visibility  into  the  SPO/NWC  organization  itself.  The 
Production  Manager  and  SPO/NWC  Manager  must  know  which 
responsibilities  or  tasks  are  not  being  fulfilled  so  that 
they  may  bring  additional  resources  to  bear  if  required. 

This  can  be  accomplished  by  an  overdue  task  reporting  system. 
This  system  would  be  an  exception  reporting  system  by  nature 
and  would  identify  those  specific  areas  which  require  mana- 
gerial attention. 

The  second  objective  of  the  managerial  control 
subsystem  is  visibility  of  external  areas  essential  to  the 
accomplishment  of  program  tasks  and  objectives.  These  areas 
include  the  functional  codes  within  NWC  and  other  activities 
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which  interact  with  SPO/NWC,  as  outlined  in  Chapter  III. 

The  Production  Manager  and  SPO/NWC  Manager  have  a need  to 
-know-  the-  level—  ef-werk-Io-ad-  wi.thin^-thfi£je. .activities  in.  order, 
to  make  appropriate  resource  allocations  and  tradeoffs  in 
light  of  program  goals.  The  level  of  workload  intended  here 
would  reflect  only  SPO/NWC  tasks  to  be  performed  by  these 
activities.  This  visibility  would  allow  the  Production 
Manager  and  SPO/NWC  Manager  to  establish  priorities  among 
the  various  SPO/NWC  tasks  which  a particular  activity  was  to 
perform  in  the  face  of  limited  resources  within  that  organi- 
zation, or  to  request  and/or  provide  additional  resources 
for  the  completion  of  critical  tasks. 

In  addition  to  the  level  of  workload  within  the 
supporting  activities,  the  SPO/NWC  Manager  needs  to  know  the 
level  of  funding  and  expenditures  as  applicable  to  the  tasks 
performed  by  these  activities.  This  visibility  would  only 
be  required  at  the  customer  order  level;  however,  it  would 
be  very  important  in  providing  insight  to  resource  utiliza- 
tion and  progress  of  task  accomplishment. 

A final  objective  of  this  managerial  control  ele- 
ment of  the  MICS  is  the  recording  and  processing  of  his- 
torical task  accomplishment  data  for  planning  purposes. 

This  capability  would  enable  the  SPO/NWC  Manager  to  plan 
future  workload  and  funding  requirements  by  providing  such 
information  as  the  average  task  processing  time  by  component 
area  by  a particular  functional  code.  Another  example  would 
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be  the  average  cost  per  task  by  component  area  by  a func- 
tional code.  This  would  be  particularly  helpful  and  appli- 
cable in  the  processing  of  ECPs  and  CDIs.  While  no  model  is 
envisioned  which  would  predict  with  extreme  accuracy  the 
cost  and  time  parameters  of  a particular  future  task,  the 
analysis  of  historical  data  would  provide  some  insight  into 
future  resource  requirements. 

C.  EVALUATION  OF  CURRENT  INFORMATION  AND  CONTROL  SYSTEMS 
1 . Operational  Control 

The  goals  and  objectives  of  an  MICS  were  enumerated 
in  the  previous  section  of  this  chapter.  The  operational 
control  objectives  as  established  are:  1)  a closed-loop 

task  tracking  system,  i.e.,  a means  to  identify  tasks  that 
are  completed  or  not  completed,  2)  a uniform  method  and 
format  for  task  control,  3)  funding  visibility  at  the  JO 
level,  and  4)  a record  of  completed  task  data. 

Evaluation  of  the  current  MICS  against  these  objec- 
tives highlights  the  deficiencies  or  adequacies  of  present 
practices.  The  results  of  this  analysis  will  indicate  the 
problem  areas  that  need  improvement  and  point  out  areas  that 
must  be  dealt  with  if  development  of  a new  system  is  neces- 
sary. 

A closed-loop  task  tracking  system  is  the  number 
one  objective  of  the  SPO/NWC  MICS.  Neither  the  correspond- 
ence, filing  and  distribution  system,  the  task  agreement 
system,  nor  the  program  review  action  item  system  provide 
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the  closed- loop  system  desired.  None  of  these  systems,  as 
structured,  provides  the  visibility  to  ascertain  if  re- 
quested action  has  been  completed. 

The  D/CM  system,  Mark  III  Management  System  and 
funding  system  individually  possess  the  characteristics  of  a 
closed- loop  system.  The  major  problem  is  that  they  do  not 
tie  back  into  the  correspondence  system  and  therefore  pro- 
vide a closed-loop  only  on  a subsystem  level.  In  addition, 
these  systems  require  manual  updating  and  information  re- 
trieval and  subsequently  are  very  time  consuming.  Since 
they  do  not  provide  due  date  sequencing  or  exception  data, 
this  type  of  information  must  be  retrieved  by  a search 
through  the  entire  file. 

As  is  evident  in  the  discussion  of  the  existing 
SPO/NWC  information  and  control  system  in  the  preceding 
chapter,  the  existing  system  is  made  up  of  a number  of 
disjointed  systems.  There  is  no  uniform  method  and  format 
for  task  control.  Each  of  the  existing  systems  is  designed 
to  perform  information  and  control  functions  in  specific 
areas  and  does  not  attempt  to  integrate  the  information  into 
a single  format  at  either  the  operational  or  managerial 
levels.  As  a result,  a Project  Engineer,  the  Production 
Manager,  and/or  the  SPO/NWC  Manager  must  go  to  three  or  four 
different  reports  or  files  to  determine  the  status  of  work 
under  his  cognizance.  The  time  required  to  accomplish  this 
is  considered  excessive. 
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The  individual  Project  Engineers  keep  their  own 
personal  tracking  system  of  notebooks  or  chalkboard  entries, 
each  with  his  own  format.  This  makes  tracking  or  interpre- 
tation of  status  difficult  in  the  absence  of  one  of  these 
individuals.  The  absence  of  a predetermined  format  and 
system  for:  1)  program  review  action  item,  and  2)  miscel- 

laneous requests  for  task  accomplishment,  which  do  not  fall 
into  one  of  the  predetermined  categories  in  existence  re- 
sults in  the  loss  of  data  connected  with  the  completion  of 
these  tasks.  In  fact,  some  of  the  requests  probably  do  not 
ever  get  accomplished  and  are  never  brought  to  light  since 
there  is  no  system  to  record  and  track  their  progress. 

The  funding  process  at  the  JO  level  is  adequate  in 
that  a system  is  available  for  SPO/NWC  use.  However,  as  it 
is  being  used,  it  does  not  provide  the  cost-performance 
tracking  of  tasks  at  a level  that  the  Project  Engineer 
needs.  The  mechanism  exists  but  the  implementation  is 
lacking.  The  lack  of  cost  visibility  at  the  JO  level  is  a 
problem  in  each  of  the  current  MICS  systems.  D/CM  and  Mark 
III  systems  have  JO  control  but  it  is  at  such  a level  that 
the  expenditures  for  any  given  ECP  review  are  unknown  and 
only  averages  can  be  determined.  A similar  situation  exists 
with  the  program  review  action  items  in  that  all  expendi- 
tures for  all  items  in  a functional  code  are  charged  against 
a general  task  agreement  and  no  visibility  is  provided  on 
any  particular  action  item  task. 
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2 . Managerial  Control 


The  managerial  control  objectives  of  the  desired 
SPO/NWC  MICS  are:  1)  visibility  into  the  SPO/NWC  organiza- 

tion, 2)  visibility  into  external  areas,  3)  expenditures 
level  summaries,  and  4)  historical  summaries  on  completed 
tasks.  Analysis  of  the  current  MICS  in  light  of  these 
objectives  will  determine  the  adequacies  or  deficiencies  of 
the  current  practices. 

The  current  information  and  control  systems,  with 
the  exception  of  the  funding,  do  not  provide  managerial 
visibility  into  the  SPO/NWC.  Neither  the  correspondence  and 
filing  system,  D/CM  system,  program  review  action  item 
system,  nor  Mark  III  system  provide,  on  a scheduled  basis, 
any  data  on  past  due  or  delinquent  tasks.  This  type  of 
past-due  tasks  information  can  be  located  in  D/CM  card  files 
but  it  is  not  readily  available. 

A similar  situation  exists  with  visibility  into  the 
SPO/NWC  functional  support  organization.  The  current  infor- 
mation and  control  systems  do  not  provide  any  type  of  excep- 
tion reporting  or  workload  levels.  Visibility  is  available 
through  the  monthly  technical  reports  on  past  performance- 
only.  There  is  no  means  to  highlight  workload  difficulties 
and  therefore  allow  the  SPO/NWC  to  set  priorities  or  reallo- 
cate resources. 

The  current  funding  system  provides  adequate  re- 
porting on  the  financial  status  of  the  program  at  the  cus- 
tomer order  level. 
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Historical  file  data  using  the  current  information 
and  control  systems  is  deficient  in  that  there  is  no  central 
file  system  to  retrieve  information  on  past-due  tasks. 
Historical  data  must  be  retrieved  manually  from  a diverse 
number  and  type  of  files,  and  subsequently  manipulated  by 
hand  to  produce  the  desired  information. 

3 . Summary  and  Conclusions 

The  evaluation  of  current  information  and  control 
systems,  in  light  of  the  goals  and  objectives  established  by 
the  authors,  highlights  deficiencies  in  the  following  areas: 
1)  closed- loop  tracking,  2)  uniform  format/methods,  3) 
management  visibility,  and  4)  historical  filing.  In  order 
to  eliminate  these  deficiencies,  the  authors  will  present  a 
conceptual  model  of  a MICS  for  the  SPO/NWC. 

D.  SPO/NWC  MICS  CONCEPTUAL  MODEL 

The  conceptual  model  of  the  desired  SPO/NWC  MICS  is 
primarily  a pictorial  or  diagrammatic  presentation  of  the 
system  inputs  and  outputs.  The  system  inputs  are  the  var- 
ious means  of  task  and  responsibility  assignments  discussed 
in  Chapter  III.  The  outputs  consist  of  reports  designed  to 
attain  the  system's  overall  goals  and  objectives  as  discussed 
in  the  previous  section.  The  conceptual  design  model  of  the 
SPO/NWC  MICS  is  presented  as  Figure  IV- 1. 
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E.  DEFINITION  OF  SYSTEM  OUTPUTS 

This  section  will  discuss  in  detail  the  outputs  shown 
on  the  conceptual  design  model.  Each  report  will  be  out- 
lined in  turn,  depicting  the  specific  information  fields 
required  to  prepare  the  output,  the  retrieval  time  and 
frequency  needed,  the  volume  of  information  to  be  reported, 
and  the  number,  dissemination,  and  output  security  involved 
with  each. 

1.  Outstanding  Tasks  Listing 

As  described  in  the  previous  chapter,  the  Project 
Engineer  is  a very  key  individual  in  the  accomplishment  of 
SPO/NWC  responsibilities.  Correspondence  goes  directly  to 
the  appropriate  Project  Engineer,  via  the  "programmed" 
correspondence  distribution  system.  He  is  responsible  for  _ 
the  assignment  of  tasks  to  the  functional  codes  and  other 
activities  and  the  monitoring  of  progress  on  the  task  comple- 
tion. A viable,  comprehensive  MICS  must  provide  the  Project 
Engineer  with  an  improved  capability  to  discharge  his  respons- 
ibilities. The  purpose  of  the  outstanding  tasks  listing  is 
to  assist  the  Project  Engineer  by  providing  a uniform  and 
comprehensive  means  by  which  each  task  assigned  to  NWC 
functional  codes  and  other  activities  may  be  tracked. 

In  order  to  accomplish  this,  the  listing  must 
contain  the  subject  of  the  specific  task,  the  responsible 
code  or  activity  name,  the  completion  due  date,  the  task 
initiating  documentation,  and  the  form  of  the  required 
reply.  This  information  will  allow  the  Project  Engineer  to 
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keep  track  of  what  the  task  is,  who  is  responsible  for 
completion,  and  when  completion  is  required.  It  also  indi- 
cates who  or  what  activity  requested  the  performance  of  the 


task  and  what  the  desired  response  is  to  be,  i.e.,  a report, 
letter,  memorandum, presentation,  etc.  The  output  report 
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should  also  contain  an  entry  indicating  the  amount  of  funds 
budgeted  or  expected  to  complete  the  task  and  the  amount 
actually  expended  as  of  the  report  date.  This  funding 


should  be  broken  down  into  labor,  material,  travel,  overhead, 
and  "miscellaneous"  categories.  This  will  enable  the  Pro- 
ject Engineer  to  monitor  costs  concurrently  with  the  sched- 
ule and  performance  parameters. 

As  a means  of  organizing  the  multitude  of  tasks 
which  are  to  be  tracked  by  each  Project  Engineer,  four 
categories  should  be  delineated.  There  would  be  ECPs,  CDIs, 
Program  Review  Action  Items  and  other  tasks.  All  the 


information  items  desired  above  should  be  included  on  spe- 
cific tasks  within  each  of  these  four  categories.  In  order 
to  act  as  a "tickler"  to  the  Project  Engineer,  the  informa- 
tion items  listed  above  should  be  presented  in  due  date 
sequence  within  the  four  categories.  This  will  enable  the 
Project  Engineer  to  see  delinquent  tasks  readily,  as  well  as 
those  on  the  immediate  time  horizon. 

In  addition  to  the  due  date  sequence  listings 
within  the  four  task  type  categories,  a report  is  also 
needed,  arranged  in  responsible  code  or  activity  sequence. 
The  information  fields  would  be  the  same  as  those  in  the  due 
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date  report;  however,  this  listing  would  highlight  the 
workload  in  the  functional  codes  and  other  activites  as  well 
as  the  schedule  and  cost  performance  of  these  activities. 

The  Outstanding  Tasks  Listing  in  due  date  sequence 
would  be  tailored  to  each  Project  Engineer,  i.e.,  each 
Project  Engineer  would  receive  a listing  showing  the  tasks 
in  his  area  of  cognizance  (GCS,  AOTD , etc.,  as  applicable.) 

In  addition  ihe  D/CM  would  receive  an  aggregate  listing  of 
all  ECPs  to  enable  him  to  ascertain  those  ECPs  which  were 
late  in  the  review  cycle  and  those  which  were  nearing  the 
due  date.  The  responsible  code  or  activity  report  would  be 
provided  to  the  Production  Manager  and  SPO/NWC  Manager  to 
give  them  the  visibility  into  the  activity's  workload  levels 
and  enable  them  to  set  priorities,  make  resource  alloca- 
tions, and  determine  if  new  tasks  can  be  accepted.  It  could 
also  be  provided  to  the  functional  code  heads  to  give  them  a 
summary  of  SPO/NWC  work  to  be  performed  by  their  organization. 

A review  of  the  volume  of  tasks  outstanding  indi- 
cates that  approximately  120  items  are  outstanding  each 
month  in  the  area  of  AIM-9L  production  support.  These  items 
are  divided  among  the  four  Project  Engineers  under  the 
Production  Manager.  In  order  to  adequately  monitor  these 
tasks,  the  Outstanding  Tasks  Listing  should  be  provided  to 
the  Project  Engineers  on  a weekly  basis,  and  the  information 
provided  shall  not  be  more  than  seven  days  old.  The  respon- 
sible code  or  activity  report  should  be  provided  to  the 
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Production  Manager  and  the  SPO/NWC  Manager  every  two  weeks 
and  should  not  present  information  more  than  seven  days  old. 

2 . Overdue  Tasks  Listing 

The  Overdue  Tasks  Listing  would  provide  the  Produc- 
tion Manager  and  SPO/NWC  Manager  with  visibility  into  the 
SPO/NWC  organization  itself  and  highlight  those  areas  which 
require  managerial  attention.  The  information  provided 
would  be  the  same  as  presented  in  the  Outstanding  Tasks 
Listing;  however,  only  those  unaccomplished  tasks  which  had 
surpassed  the  completion  date  would  be  listed.  The  Produc- 
tion Manager  would  receive  a weekly  listing  showing  all 
tasks  overdue  by  five  or  more  days  and  the  SPO/NWC  Manager 
would  receive  a weekly  listing  showing  all  tasks  overdue  by 
ten  or  more  days.  Both  of  the  reports  would  be  in  due  date 
sequence;  however,  the  cognizant  Project  Engineer  and  func- 
tional code  would  also  be  listed  so  that  dissemination  of 
this  report  should  be  restricted  to  the  Production  Manager 
and  SPO/NWC  Manager  only. 

3 . Completed  Tasks  Listing 

The  purpose  of  the  Completed  Tasks  Listing  is  to 
provide  a record  of  task  accomplishments  and  thereby  close 
the  loop  which  was  begun  upon  the  receipt  of  a request  for 
task  accomplishment.  In  addition,  it  would  provide  a data 
base  for  projections  of  future  requirements  and  capabili- 
ties. The  basic  information  elements  which  were  established 
by  the  Outstanding  Tasks  Listing  would  be  retained  on  the 
Completed  Tasks  Listing  and  the  completion  date,  outgoing 
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response  identification  number  (e.g.,  letter  serial  number 
message  date-time  group),  total  costs,  and  time  to  complete 
the  task  would  be  added.  This  listing  should  be  arranged  in 
incoming  requestor  documentation  identification  number 
sequence  in  order  to  tie  specific  responses  to  specific 
requests.  This  would  enable  SPO/NWC  personnel  to  retrieve 
the  requested  information  at  a later  time  through  the  use  of 
the  original  requestor  identification  number. 

Only  one  listing  would  be  required  and  should  be 
provided  on  a bi-weekly  basis.  It  should  contain  the  accum- 
ulation of  up  to  the  previous  six  months  information.  After 
the  accumulation  of  six  months  information,  the  last  listing 
would  be  retained  and  a new  cumulative  listing  would  be 
initiated.  Based  upon  the  average  number  of  tasks  outstand- 
ing, it  is  anticipated  that  in  a six-month  period  approxi- 
mately 750  task  accomplishments  would  be  recorded. 

4 . Historical  Information  Summaries 

The  planning  and  estimating  for  future  workloads 
and  tasks  is  an  important  element  of  the  SPO/NWC  Manager 
responsibility.  With  the  application  of  many  years  of 
experience  and  by  repeating  similar  tasks,  the  planned 
details  become  more  accurate  in  terms  of  cost,  schedule  and 
performance.  However,  when  personnel  change,  the  corporate 
memory  is  lost  and  another  training  period  begins. 

The  data  base  established  by  the  Completed  Tasks 
Listing  would  retain  the  needed  task  accomplishment  data. 
This  data  could  be  manipulated  to  produce  information  on  an 
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"as  required"  basis  to  furnish  the  SPO/NWC  Manager  with  such 
outputs  as  average  time  and/or  cost  for  task  completion  of  a 
certain  type  by  a given  functional  code  or  PFA.  This  type 
of  information  could  be  used  to  answer  "what  if"  questions 
and  also  to  evaluate  the  efficiency  of  a particular  func- 
tional code  or  PFA. 

5 . Funding  Summaries 

Funding  summary  reports  are  essential  to  provide 
the  fiscal  information  necessary  to  manage  the  SPO/NWC. 

Funding  reports  for  the  managerial  level  should  include 
funding  received  by  NWC,  planned  expenditures,  actual  expend- 
itures, and  cumulative  expenditures  for  the  fiscal  year  by 
customer  order.  A further  breakdown  of  actual  expenditures 
into  labor,  overhead,  material,  travel,  contracts  and  miscel- 
laneous should  be  included.  The  reports  should  be  available 
on  a monthly  basis.  This  will  allow  program  visibility  in 
time  to  avoid  over  expenditures. 

The  number  of  reports  would  be  small  since  only  one 
copy  per  customer  order  number  is  required.  AIM-9L  produc- 
tion  support  would  have  only  one  report  per  month. 

The  report  should  be  disseminated  to  the  SPO/NWC 
Manager  and  the  Production  Manager.  The  fiscal  assistant 
would  keep  and  maintain  file  copies.  The  same  report  could 

1 

then  be  used  for  NAVAIR  and  NWC  management  reports . 

The  summary  funding  reports  would  provide  a means 
? to  track  and  control  expenditures  at  the  managerial  level. 
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It  would  be  available  for  upper  management  reports  and 
should  not  require  any  output  security  restrictions. 


F.  DEFINITION  OF  PROCESSING  REQUIRED 

Having  determined  the  characteristics  of  the  outputs 
required  by  the  desired  SPO/NWC  MICS,  it  is  possible  to 
provide  a general  set  of  requirements  for  the  processing 
function  of  the  system.  As  described  in  Chapter  II,  the 
processing  functions  can  be  viewed  in  terms  of  response 
time,  frequency,  data  volume,  data  manipulation  and  storage 
or  file  requirements. 

The  frequency  of  the  output  required  and  the  currency 
of  the  information  desired  will  affect  the  response  time  and 
frequency  of  the  processing  operations.  In  order  to  provide 
weekly  listings  with  information  less  than  seven  days  old 
requires  a system  processing  time  of  one  day.  The  response 
time  of  the  processing  function  must,  therefore,  be  one  day. 
However,  the  frequency  of  the  update  would  be  weekly.  Those 
reports  which  are  required  bi-weekly  would  result  in  an 
update  frequency  of  bi-weekly  with  a processing  response 
time  of  one  day  in  order  to  provide  information  with  a 
currency  of  seven  days.  Similarly  monthly  reports  would 
require  monthly  updating.  The  "as  required"  reports  would 
not  require  as  immediate  a response  time.  Three  days  would 
be  sufficient  to  respond  to  most  "what  if"  questions  and 
since  the  information  would  be  historical,  there  would  not 
be  any  strict  restrictions  in  the  currency  of  the  data. 
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The  data  volume  would  be  dependent  upon  the  number  of 


tasks  assigned  during  the  period  and  the  amount  of  data 
recorded  for  each  task.  The  number  of  tasks  has  been  pre- 
viously estimated  at  120  per  month,  and  the  information 
fields  required  were  enumerated  under  the  discussion  of  the 
Outstanding  Tasks  Listing  and  the  Completed  Tasks  Listing. 

The  storage  or  file  requirements  would  be  determined  by 
the  volume  characteristics  described  above,  the  number  of 
variations  of  the  basic  reports  required,  and  the  length  of 
time  for  which  the  data  must  be  retained.  The  Outstanding 
Tasks  Listing  has  three  variations:  the  due  date  sequence 

listing,  the  responsible  activity  listing  and  the  aggregated 
ECPs  listing.  The  Overdue  Tasks  Listing  would  be  provided 
in  two  variations.  The  Completed  Tasks  Listing  would  be  a 
single  listing  with  no  variations.  The  funding  summaries 
would  require  arrangement  of  the  data  by  customer  order. 

The  Historical  Information  Summaries  would  require  the 
arrangement  c the  completed  task  data  by  functional  code  or 
PFA  and  subject  category  to  enable  future  processing  to 
provide  the  desired  information.  The  number  of  files  ac- 
tually required  to  provide  the  data  outputs  represented  by 
the  various  reports,  will  be  dependent  upon  the  data  proces- 
sing method  selected  for  the  MICS.  A manual  or  electromech- 
anical method  would  require  separate  files  for  each.  An  EAM 
or  punched  card  equipment  method  could  use  a single  or  small 
number  of  card  files  and  merely  re-sort  them  each  time  a new 
variation  of  output  is  required.  An  electronic  computer 
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could  utilize  separate  file  storage  or  a data  base  storage 
system  as  deemed  appropriate. 

The  outstanding  tasks  data  would  be  changing  constantly 
over  a period  of  time  but  would  retain  approximately  the 
same  volume  level  as  previously  indicated.  The  completed 
tasks  data  would  be  retained  in  a file  arrangement  for  six 
months;  therefore,  the  file  would  contain  about  750  tasks. 

Processing  operations  would  be  required  to  provide  the 
listings  as  described  in  the  output  definition  section. 

These  could  be  done  manually  or  with  machine  and  the  extent 
of  urocessing  would  be  determined  by  the  number  and  type  of 
files  maintained.  Obviously,  if  a separate  file  were  main- 
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tained  for  each  type  of  report,  no  processing  would  be 
required  other  than  compiling  the  information  into  a report 
itself.  The  Historical  Information  Summaries  would  require 
calculation  of  average  cost  and  time.  Also,  calculation  of 
ranges  of  values  or  variances,  and  standard  deviation  from 
the  mean  values  could  be  required. 

G.  DEFINITION  OF  INPUTS  REQUIRED 

The  input  sources  for  the  desired  SPO/NWC  MICS  are 
shown  in  the  Conceptual  Design  Model  (Figure  IV-1) . The 
primary  personnel  to  actually  input  data  to  the  system  would 
be  the  Project  Engineers.  Upon  receipt  of  a task  assign- 
ment, the  appropriate  Project  Engineer  would  fill  out  a 
formatted  input  data  sheet  with  the  required  information. 
This  basic  document  would  then  become  the  instrument  for 
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taking  the  transaction  up  in  the  MICS.  Updating  would  also 
be  done  by  the  Project  Engineer;  however,  the  insertion  of 
the  completion  data  indicating  task  accomplishment  could 
only  be  done  by  the  Production  Manager  or  SPO/NWC  Manager . 
Verification  of  input  data  would  be  required  before  allowing 
the  data  to  enter  the  MICS. 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY 

This  thesis  represents  a comprehensive  review  of  the 
current  literature  on  MICS  theory  and  applications,  and  a 
thorough  review  of  the  current  SPO/NWC  organization  and  MICS 
by  the  authors.  Goals  and  objectives  for  a viable  SPO/NWC 
MICS  were  established  in  light  of  the  theoretical  management 
practices  appropriate,  and  the  needs  of  the  SPO/NWC.  An 
evaluation  of  the  current  SPO/NWC  information  and  control 
systems  was  made  with  respect  to  the  established  MICS  goals 
and  objectives,  and  the  current  systems  were  'found  to  be 
deficient  as  noted  in  the  preceding  chapter.  An  improved 
MICS  was  therefore  deemed  necessary  by  the  authors,  and  a 
conceptual  model  was  presented  representing  a viable,  compre- 
hensive MICS  for  the  SPO/NWC. 

B.  CONCLUSIONS 

The  authors  concluded  in  Chapter  IV  that  the  current 
SPO/NWC  information  and  control  systems  failed  to  meet  the 
desired  performance  in  the  areas  of  operational  control  and 
managerial  control.  Specifically,  deficiencies  were  noted 
in  the  areas  of  closed-loop  task  tracking,  uniform  format/ 
methods,  management  visibility,  and  historical  filing.  In 
order  to  eliminate  these  deficiencies,  a conceptual  model 
of  an  improved  MICS  was  presented.  The  alternatives  to 
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providing  an  improved  MICS  are  the  redesign  or  revision  of 
the  current  MICS,  or  the  design  of  a totally  new  MICS  struc- 
ture. 


C.  RECOMMENDATIONS 


1.  MICS  Revision  and  Augmentation 

It  is  the  authors ' recommendation  that  the  present 
MICS  be  revised  and  augmented.  Design  of  a totally  new  MICS 
structure  is  not  considered  necessary.  The  revision  of  the 


existing  systems  would  adapt  the  adequacies  of  existing 
systems  to  the  characteristics  of  the  conceptual  model,  and 
the  augmentation  of  currently  lacking  capabilities  would 
provide  the  feedback  and  visibility  required. 

What  is  envisioned  is  an  integrated  MICS  utilizing 
the  existing  systems'  structures  but  introducing  a common, 
uniform,  input  documentation  to  provide  a single  means  of 


tracking  and  recording  task  accomplishment  within  the  exist- 
ing systems.  These  existing  systems  would  then  become 
subsystems  of  the  integrated  MICS.  This  approach  would 
utilize  the  existing  adequacies  of  these  current  methods  and 
would  assist  in  providing  the  added  operational  and  manager- 
ial control  required. 

The  introduction  of  a feedback  mechanism  to  produce 
a closed-loop  task  tracking  system  would  provide  the  infor- 
mation required  for  adequate  operational  control  and  mana- 
gerial control.  This  information  would  then  become  the 
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basis  for  the  reports  previously  described  which  are  not 
available  under  the  current  system. 

2 . Data  Processing  Method 

The  data  processing  method  required  for  this  inte- 
grated MICS  could  be  any  of  the  four  methods  discussed  in 
Chapter  II;  however,  the  authors  recommend  that  either  an 
EAM  or  computer  method  be  investigated  for  application. 

This  recommendation  is  based  upon  the  volume  and  time  con- 
straints represented  within  the  conceptual  model,  as  out- 
lined in  Chapter  IV. 

3 . Participatory  Management  and  Design 

As  pointed  out  in  Chapter  IV,  the  Project  Engineer 
is  a principal  benefactor  and  key  individual  in  the  initia- 
tion and  updating  of  information  in  the  MICS.  It  is  there- 
fore recommended  that  these  individuals  be  participants  in 
the  subsequent  design  and  implementation  of  an  improved  MICS 
as  advocated  by  the  authors.  Any  MICS  can  only  be  effective 
if  all  concerned  understand  it  and  use  it  to  its  fullest 
advantage . 

4 . Follow-on  Study 

As  noted  in  the  Methodology  section  of  Chapter  I, 
this  thesis  represents  the  first  three  phases  of  the  MICS 
development  cycle.  It  is  recommended  that  a follow-on  study 
be  conducted  in  accordance  with  the  MICS  Development  Model 
to  complete  the  Preliminary  Design  and  allow  the  SPO/NWC  to 
actively  pursue  the  total  design,  development  and  implement- 
ation of  the  required  MICS. 


114 


APPENDIX  A 
NAVAIR  ORGANIZATION 


OFFICES  TECHNOLOGY  FLEET  SUPPORT  ACQUISITION  EVALUATION 

(PMAs)  02  03  04  05  06 
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APPENDIX  B 

NAVAIR— NWC  SIDEWINDER  PROGRAM  INTERFACES 


PROJECT  ENGINEER 

AIR— 5105B1 

PROJECT  OFFICE 

AIR— 5105B2 

CONTRACTING  OFFICER 

AIR-21611 

CONTRACT  SPECIALIST 

AIR— 2161 1J 

LOGISTICS 

AIR— 41041 A 

MATERIAL  MANAGEMENT 

AIR— 4122B2 

TRAINING  EQUIPMENT 

AIR— 4135C 

NARF  WORKLOAD  SCHEDULE 

AIR— 4144E 

GSE  LOGISTICS 

AIR—41721C 

CONTRACT  PRICING 

AIR -50632 

HERO/SAFETY 

AIR-52024 

HERO/SAFETY 

AIR -52024 A 

RELIABILITY 

AIR-52051 

RELIABILITY  AIR- 

-5205/ESA— 1 154 

AERODYNAMICS 

AIR-530113 

LAUNCHER  POWER  SUPPLY 

AIR-5321  IB 

LAUNCHER 

AIR-53212 

9H/L  S&A,  FUZES 

AIR -53241 

9L  S&A,  FUZES 

AIR— 53241B 

WARHEADS 

AIR— 53242A 

9H/CHAP— GCG,  WINGS,  FINS 

AIR— 533313A 

9L-GCS,  WINGS,  FINS 

AIR— 533323C 

LAUNCHER  TEST  EQPT 

AIR— 53441C 

MISSILE  TEST  EQPT 

AIR— 5344J  B 

HANDLING  EQUIPMENT 

AIR-53443 

CONTAINERS 

AIR— 53443C 

MOTORS,  GAS  GENERATORS 

AIR— 53663C 

SHIP  INSTALLATIONS/ 
AIRCRAFT  SUPPORT 

AIR -5371 2 

QUALITY  ASSURANCE 

ESA- 11 123 

PRODUCTION 

ESA- 2041 D 

PRODUCTION 

ESA-2041  D1 

PRODUCTION 

ESA -64 

COST  DATA 

ESA— 2083B 

PROCUREMENT  BUDGET 

ESA-201 2A 

PRODUCTION  SUPPORT 

ESA-61  A 

LEGAL  COUNSEL 

AIR— 00C 
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APPENDIX  C 
NWC  ORGANIZATION 


APPENDIX  D 

ENGINEERING  DEPARTMENT  ORGANIZATION 


APPENDIX  E 

SPO/NWC  - NWC  FUNCTIONAL  ORGANIZATION  INTERFACES 


CODE  3656 


APPENDIX  F 

SIDEWINDER  PROGRAM  OFFICE  (NWC) 


COMPONENTS 


APPENDIX  G 

SPO/NWC— PFA  INTERFACES 


r 


SIDEWINDER  PROGRAM  OFFICER 
CODE  36202 

NAVAL  WEAPONS  CENTER 
CHINA  LAKE 


r PACIFIC  MISSILE  TEST  CENTER 
PT.  MUGU,  CA. 

1-  FLEET  ANALYSIS  CENTER 
CORONA.  CA. 

L-  NAVAL  ORDNANCE  STATION 

• INDIAN  HEAD,  MD. 

I 

EGLIN  AIR  FORCE  BASE 
| FT.  WALTON  BEACH,  FL. 

' NAVY  GAUGE  AND  STANDARDS  LAB 

1 POMONA,  CA. 

I 

NAVAL  WEAPONS  SUPPORT  CENTER 
, CRANE,  IN. 

• OGDEN  AIR  LOGISTICS  COMMAND 

• OGDEN,  UTAH 

I 

r - AJR  FORCE  TEST  AND  EVALUATION 
. CENTER,  KIRTLAND,  N.M. 

L-  NAVAL  ORDNANCE  LABORATORY 
I LOUISVILLE 

I 

»-  NAVAL  WEAPONS  LABORATORY 
DAHLGREN 


ECP  LOGISTIC  IMPACT 
TEST  EQUIPMENT  CERTIFICATION 
ROCKET  MOTOR  TECHNICAL  SUPPORT 
AIR  FORCE  TECHNICAL  REQUIREMENTS 
GAUGES 

WARHEAD  SUPPORT/MANUFACTURER 

IN-SERVICE  MISSILE  AND  UTILIZATION  DATA 

TEST  SUPPORT 

CONTAINER  PROCUREMENT 

ELECTROMAGNETIC  REQUIREMENTS 
AND  TEST 
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SPO/NWC  - SIDEWINDER  COMPONENT  CONTRACTORS  INTERFACES 


r- 

I 

I 

b 

I 

b 

I 

I- 

I- 

I- 

I- 

I- 
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b 

b 
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SIDEWINDER  PROGRAM  OFFICE 
CODE  36202 


RAYTHEON  COMPANY 

AERONUTRONICS-FORD 

SANTA  BARBARA  RESEARCH  CENTER 

MARTIN  MARIETTA 

ROCKETDYNE 

BERMITE 

MICRONICS 

ERI 

CRANE-NAVAL  WEAPONS 
SUPPORT  CENTER 

LOCKLEY  MFG  COMPANY 


- GUIDANCE  & 

SECTION 

- GUIDANCE  & 

SECTION 

- FUSE 

- FUSE 

- MOTOR 

- MOTOR 

- SAFETY  AND 

DEVICE 

- WINGS 

- WARHEAD 

- FIN 


CONTROL 

CONTROL 


ARMING 
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DEPARTMENT  OF  THE  NAVY 
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HWIHOlCa.  O.C.  2G]GO 


See  MAVAin  3900. 8 or  P'lp+rsc J'tr 
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UNCLASSIFIED 


Commander  (Code  552C2) 
Naval  Weapons  Center 
China  Lake,  CA  93555 


fcAVAl*  noj  40  1*0*44* 


IAIE-05?/ 
JESA-2041 


A 0 5 P - 2 0 4 / 2 1 6 2 /6000/MOOO 


Normal 


COSSif  ICAT  10*  Of  AT/«U 

UNCLASSIFIED 


V/.  Groove,  Jr.  [ ESA- 20 41 


1.  Th«  AlBTC:XACaAXX>COE:i3<XKMXd  = »crib.J  b«lo»  is  sssijn.d  in  accord.oc.  »icb  th«  indicated  effort.  le.«I  <nd  schedule:  Food 

ing  suthor  i is  t ion  for  AIKTAibS  .ill  be  provided  in  separate  correspondence.  IX  this  AIBTASK>f^OC<XXj4X}<X>!5J>T  canr.ot  be  accco- 
pltshed  as  assigned,  advise  the  Cos.ander,  fiasal  Air  Systeas  Cocuaand,  and  the  NAVA  Klb'XSCCM  Tt.e  COCMUKlATCR.  if  applicable. 

No  work  beyond  the  planning  phase  will  be  accomplished  unless  the 
addressees  have  funds  in  hand  or  written  assurance  thereof. 

2.  CANCELLATION,  REFERENCES,  AND/OR  ENCLOSURES: 


3 . TECHNICAL  I N S TF. U C T 1 0 N S •: 

a.  Title : Production  Support  of  Air  Launched  Guided  Missile 

’Weapon  Systems. 

b.  Purpose : The  purpose  .of  this  AIRTASN  is  to  assign  to  the 

M5ir.pt.tr.rK  ru--:- ia  T.o’.-a' the  production  support  responsibilities  for 

Air  Launcned  Guided  Missile  Weapon  Systems  as  set  forth  herein. 

c.  Background : The  policy  of  the  Naval  Air  Systems  Command 

(AIR-05P/ESA-20 ) is  to  delegate  to  specified  field  activities  certain 
functions  required  in  support  of  the  production  of  ALGM  (Air  Launched 
Guided  Missiles).  The  assignment  of  Production  Support  to  specified 
field  activities  will  further  consolidate  engineering  functions  and 
provide  optimum  interface  between  Basic  Design  Engineering,  Integrated 
Logistics  Support,  Maintenance  Engineering  and  Production  Support. 

d.  Detailed  Requirements : “Under  this ' AIRTASK  NAWPMcmy 

China  Lake £ shall  support  -NAVAIR  by  performing  assignee 

tasks  as  directed  by  NAVAIR  (AIR-05?/ESA-20 ) in  work  assignments  issuec 
relative  to  Data  Management  Support,  Configuration  Management  Support, 
Product  Assurance  Support,  and  Administrative  Support. 


||  Sl^t.Iw.l  (it  Dll. Cl... 

fc  fh  ■ 

w.  J.  HUGHES , BY-' DIRECT  ION  - 

to  v*gs;f  / 
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(1)  Data  Management  Support: 


AIRTASX  NO.  A05P-20V216/6000/ 

0000  Amend 


r 


provide 

related 


(a)  Coordinate  review  and  up-dating  of 
current  data  packages  for  reprocurement  of 
equipment  or  elements  thereof. 


data  so  as  to 
assigned  systems  , 


(b)  Assist  NAVAIR  (AIR-05P/ESA-204 ) 
requirements  as  required. 


in  definition  of  data 


(2)  Configuration  .Management  Support: 

(a)  Coordinate  configuration  mangement  (identification 
control,  and  status  accounting)  efforts  so  as  to  provide  current 
product  baselines  and  configuration  traceability  for  assigned  systems 
related  equipment  or  elements  thereof. 


(b)  Review  for  system  impact  and  submission  to  NAVAIR  of 
recommendations  concerning -Class  I ECP  and  critical/maj or  waiver  and 
deviation  requests. 

(c)  Review  for4  system  impact  of  Class  II  ECP  and  minor 
waiver  and  deviation  requests.  Technical  approval  of  Class  II  EC? 

and  minor  waiver  and  deviation  requests  when  specified  by  the  production 
cntract . 


(d)  As  required,  conduct  configuration  audits. 

(3)  Product  Assurance  Support: 


(a)  Participate  in  pre-  and  post-award  surveys,  quality 
audits,  contractor/contracting  officer  technical  meetings  and  facility 
conferences  as  required. 

(b)  Conduct  GLAT  (Government  Lot  Acceptance  Testing)  or 
provide  technical  support  therefor,  as  required. 

(c)  Perform  comparative  trend  analysis  of  production  test 
data,  field  test  data,  and  performance  data  to  evaluate-  system  per- 
formance,. quality,  and  reliability.  Adverse  trends  and  recommendations 
for  corrective  action  shall' be  reported  to  NAVAIR  (AIR-05P/ESA-204 ) 
immediately. 

(d)  Review  production  specifications , assembly  and  test 
instructions,  quality  assurance  procedures,  and  reliability  require- 
ments for  assigned  systems  to  determine  correlation  of  assembly,  test, 
quality  and  reliability  requirements  during  production,  assembly  and 
test  and  delivery  of  the  RE I round  to  inventory. 


bi 


li 


(e)  Coordinate  quality 
ty  of  such  efforts  with 


and  reliability  efforts 
system  requirements. 


to  assure 


125 


r 


1 0 5 p- 2 0 21. 6 2/ 6 n 0 0/ 0 0 0 0 0 

Amend  0 

(f)  Provide  test  equipment  certification  and  correlation 
for  each  assigned  system. 

(g)  Maintain  management  reporting  systems  as  established 
at  FMSAEG  (Fleet  Missile  Systems  Analysis  and  Evaluation  Group) 

(Code  25). 

(^ ) Administrative  Support: 

(a)  Coordinate  PFA  (Participating  Field  Activities) 
production  support  budget  requests  so  as  to  submit  to  NAVAIR  (AIR-05P/ 
ESA-204)  one  (i)  production  support  budget  requirement  for  each 
assigned  system. 

(b)  Submit  to  NAVAIR  (AIR-05P/ESA-204 ) for  each  assigned 
system  a quarterly  report  containing  funds  and  manhours  expended  for 
each  of  the  support  areas  contained  in  this  AIRTASK  and  allowing 
traceability  to  the  PFA  level  by  work  unit  assignment  number. 

4.  SCHEDULE: 


This  is  a continuing  -AIRTASK  assignment.  Effective  date  is 
12  Sep  1975-  .00 


REPORTS  AND  DOCUMENTATION: 


a. 

defined 


Reports:  Reporting  and  documentation  requirements  will  be 

in  the  individual  WORK  UNIT  ASSIGNMENTS  established  under 


this  AIRTASK. 


6.  CONTRACTUAL  AND  WORK  AUTHORIZATION  AUTHORITY: 

Contracts  with  industry  and  work  authorization  to  PFA’s  (Partici- 
pating Field  Activities)  to  perform  portions  of  this  AIRTASK  are 
hereby  authorized  within  the  limit  of  funds  made  available. 


7.  . SOURCE  AND  DISPOSITION  OF  EQUIPMENT : 

This  AIRTASK  includes  the  authority  to  dispose  of  equipment  acquired 
by  NAVWPMCE:i  China  .Lake  or  assigned  by  NAVAIR  for  use  in  connection 
with  this  AIRTASK,  unless  otherwise  specified. at  the  time  of  its 
assignment.  * ' • * * 

8.  AIRCRAFT  REQUIREMENTS : 

Requirements  for  testing  (PMT)  involving  aircraft  shall  be  achieved 
through  normal  channels  at  N a vwaMPR. w ny  Lake  ‘ 

COST  ESTIMATE: 

Funding  will  be  estimated  and  allocated  by  individual  WORK  UNIT 
ASSIGNMENTS. 
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1. 


AIRTASK  NO.  „ 

A05P-2OV2162/60CO/O0CO0  Amend  0 


10.  STATUS  OP  APPLICABLE  FUNDS: 


Funding  for  this  AIRTASK  v/ill  be  provided  by  separate  correspondence. 
11.  SECURITY  REQUIREMENTS: 

The  security  clearances  of  personnel  working  on  projects  under 
this  AIRTASK  and  the  security  classifications  on  documentation  and 
hardware  associated  with  this  AIRTASK  shall  be  commensurate  with  the 
classification  of  that  hardware  or  documentation  as  determined  from 
the  applicabel  security  regulations. 


Copy  to: 

Addressee  ( 5) 

PACKISTESTCENj  Pt  Mugu 
NAVA VI ON ICFAC , INDIANAPOLIS 
NAVAIRDE7CEN,  Uarminister,  PA 
“SV.'Cj  Dahlgren 
-;!SAEG  ANN,  Corona 


DEPARTMENT  OF  THE  NAVY 
NAVAL  AIR  SYSTEMS  COMMAND 
Mansion,  d.c.  20350 


Set  NAVA1B  3900.8  or  tupersedure 
for  applicable  details  on  con- 
plating  tbia  form. 


••  A) f I ASX/ WORK  UNIT  ASSIGNMENT 
. RAYA I R FOP-4  3930/1  lR£Y.  9-69) 

• > 


CLASSIFICATION 

UNCLASSIFIED 

PAGE  1 OF  1 

AOORESSEE 

Commander  (Code  55202) 
Naval  Weapons  Center 
China  Lake,  CA  93555 

AIRTASK  NO. 

A05P- 204/2162/6000/0 0000 

AMEND.  NO. 
1 

WORK  UNIT  NO. 

N/A 

AMEND.  NO. 

CFFORT  LEVEL 

NORMAL 

NAVAIR  PROJECT  engineer  coot 

AIR-05P/ 

W.  OROCME.  JR.  ESA-2041 

CLASSIFICATION  OF  AT/WU 

UNCLASSIFIED 

1.  The  AlBTASK/hEMitSiiaHiWKC^  d«,cr  ibed  below  is  assigned  in  accordance  with  the  indicated  effort  levej  and  schedule.  Fund* 
ing  authorisation  for  AlRTASkS  will  be  provided  in  separate  correspondence.  If  this  AlRTASK/&f&Xl&X^Xi&^^jiE&^  c annot  be  tccoa* 
pliahed  as  assigned,  advise  the  Commander,  Naval  Air  Systeaa  Command,  and  the  NAVAIRSYSCOM  T&£  COORDINATOR,  if  applicable. 


Request  that  the  following  changes  be  made  to  this  AIRTASK: 

a.  Change  paragraph  3 . d . ( 3 ) to  read: 

(3)  Product  Assurance  Support:  (See  Note  1) 

b.  Add  Note  1 as  follows: 

Note  1.  All  efforts  expended  in  support  of  Product 
Quality  Assurance  will  be  at  the  direction 
of  AIR-05P/ESA-4  and  as  specified  by  Work 
Unit  Assignments  issued  by  same  against 
this  AIRTASK. 


c.  Amend  paragraph  8.  to  read  "Not  applicable." 


Copy  to: 

Addressee  (5) 
PMA-259 
AIR-05P/ESA-4 
AIR-05P/ESA-2041D 
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DEPARTMENT  OF  THE  NAVY 
‘ NAVAL  AIR  SYSTEMS  COMMAND 
WASHINGTON,  O.C.  20360 


Sc®  NAVAIR  3900.8  or  supr rsrJurp 
for  applicable  details  on  com- 
pleting this  form. 


adorcs'-li 

Commander 


Naval  Weapons  Center 
(Code  55202) 

China  Lake,  CA  93555 


nav* i a MOJCCT  tv; infer 


ESA-204/AIM-9L/01 


Normal 

CLASSIFICATION  OF  AT/<*u 


I [ Unclassified 

1.  The  'CfKf&dK/WORK  UNIT  ASSIGNMENT  described  below  is  assigned  in  accordance  with  the  indicated  effort  level  and  schedule.  Fund- 
ing authorization  for  AIRTASKS  will  be  provided  in  separate  correspondence.  If  this  A2BQX3G ' *ORK  UNIT  ASSIGNMENT  cannot  be  accom- 
plished as  assigned,  advise  the  Commander,  Naval  Air  Systems  Command,  and  the  NAVAIRSYSCOM  T&£  COORDINATOR,  if  applicable. 

2 . Cancellation,  References  and/or  Enclosures. 

Ref:  AIRTASK  A05P-204/2162/6000/000000 

3.  Technical  Instruction. 

a.  Title . AIM-9L  In-House  Systems  Engineering  and  Production  Support  Activities. 

b.  Purpose.  To  define  the  production  support  services  to  be  furnished  by  Naval 
Weapons  Center  (NAVWPNCEN)  to  the  Naval  Air  Systems  Command  (NAVAIRSYSCOM)  and  the 
Naval  Weapons  Engineering  Support  Activity  (NWESA)  for  the  procurement  of  the  AIM-9L 
SIDEWINDER  Missile  System. 

c.  Background  Information.  The  NAVWPNCEN  has  been  providing  production  support 
on  the  AIM-9H  SIDEWINDER  missile  under  the  provisions  of  the  referenced  AIRTASK  and 
Work  Unit  Assignment  No.  A05P-204/AIM-9K/11 . 

d.  Detailed  Requirements.  At  the  direction  and/or  with  advance  concurrence  of 
ESA-204,  provide  the  following  production  support  activities: 

(1)  Program  Support 

(a)  As  directed  by  ESA-204 , assist  in  the  preparation  of  procurement 
requests  (PR's),  requests  for  proposals/quotations  (RFP 1 s/RFQ ' s)  and  contract 
negotiations  to  assure  the  concinuity  of  program  elements. 

(b)  Assist  ESA-204  in  the  resolution  of  production  problems. 

(c)  Assist  ESA-204  in  the  resolution  of  weapon  system  interface  problems,  ^ 

i.e.,  test  equipment,  avionics,  logistics,  and  support  equipment  (NARF  and  NWS).  A'  V* 

w 

(d)  Participate  in  Program  Review  Meetings.  \v  ^ 


SlGNATijRl  0i  re  c f I o*  tL'*4l4V4//n 


Class  i l/Lat  icw  rso  umoc* 
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(2)  Product  Assurance  Support 

(a)  Review,  analyze  and  evaluate  program  reliability  and 
maintainability  requirements,  performance,  and  demonstrations. 

(b)  Assist  ESA-204  in  the  preparation  of  specifications 
and  other  documentation  or  presentations  as  required. 

(c)  Review,  analyze  and  evaluate  product  assurance  program 
requirements,  performance  and  demonstration. 


(3)  Data  Management  Support 

Collate,  review,  and  validate  all  approved  changes  on  the 
AIM-9L  data  package.  Ensure  that  the  data  is  updated  prior  to  releasing 
for  production  procurement. 

(4)  Configuration  Management 

(a)  Evaluate  engineering  change  proposals  by  performing 
tests  on  hardware  in  the  NAVWPNCEN  laboratories  or  in  contractor's 
facilities,  as  required. 

(b)  Establish  production  baselines,  a master  documentation 
control  center,  and  configuration  management  practices. 

(c)  Monitor  contractor  compliance  with  the  product  baseline 
list  and  other  contractual  requirements  (e.g.,  reliability,  maintainability, 
etc.)  and  provide  such  other  assistance  to  the  Contractor  to  resolve 
production  problems,  specification  compatibility  problems,  and  any  other 
problems  affecting  production. 

e.  Detailed  Program  Plan.  N/A 

4.  Schedule. 

This  is  a continuing  Work  Unit  Assignment. 

5.  Reports  and  Documentation. 

a.  Submit  to  ESA-204  a quarterly  report  containing  funds  and  manhours 
expended  for  each  of  the  support  areas  contained  in  this  Work  Unit  Assignmen 
and  allowing  traceability  by  Work  Unit  Assignment  Number. 
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b.  Provide  ESA-204  with  any  suggested  update,  change  or  additional 
requirements  to  the  current  Work  Unit  Assignment,  which  is  desired  for  the 
next  years  effort.  The  revised  Work  Unit  Assignment  will  become  the  basic 
document  for  budget  submissions  and  is  required  prior  to.l  June. 

C.  Correspondence  relating  to  this  Work  Unit  Assignment  shall  be  routed 
through  ESA-204  or  as  directed  by  ESA-204. 


6.  Contractual  Authority. 

See  AIRTASK. 

7.  Source  and  Disposition  of  Equipment. 

See  AIRTASK. 

8.  Aircraft  Requirements. 

See  AIRTASK. 

9.  Cost  Estimates. 

To  be  supplied  under  separate  transmittal. 

10.  Status  of  Applicable  Funds. 

Funds  will  be  provided  by  separate  correspondence. 

11.  Security  Classification  Requirements. 

See  AIRTASK. 


Copy  to: 

NWC  55202  (5) 

PMA-259 

ESA-2012A 

ESA-2041D 

AIR-51053 
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INFORMATION  FLOW  RAW  DATA 
INCOMING  MESSAGES 
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TASK  AGK£l“EKT  - Ifi!  £RDt?AftTK£KTAL 
i1*iR-K.!O3920/l9  0*76)  S»AT  1 

I t^SK  NO.  1 AMENDMENT 

! D-19-76  1 

date  I 

11  cf2 

PNC&K# v 

AIM-9 L PRODUCTION  SUPPORT 

C3G  CL*  z 

36202 

COGNIZANT  S£-4eT  '£MT  CONTACT 

R..  W.  Doucette 

ptr.f  cc3c 

3662 

PERFORINS  ENG:  NcCR/KANAG'R 

T.  W.  Hampton 

C-‘Q  div 

362 

DIVISION  HEAD  SIGNATURE 

PERF  DIV 

366 

DIVISION  HEAD  SIGNATURE 

TASK  TITLE 

AIM-9 L PRODUCTION  ENGINEERING /MONITORING  FOR  AFT  COMPONENTS 

NC« 

DESCRIPTION  OF  WORK  REQUIRED: 


Provide  technical  monitoring  and  production  support  of  the  AIM-9L  procurement  program  for  rocket 
motors,  warheads,  safety-arming  devices,  wings  fins  and  coupling  rings. 

Responsibilities  include  data,  configuration  and  product  assurance  support  to  NAVA1R,  the  Side- 
winder Program  Office,  prime  contractors  and  subcontractors. 


APPROACH  TO  SE  TAKEN: 

DATA  SUPPORT:  Generate,  review  and  interpret  baseline  drawings  and  specifications.  Review 
and  evaluate  Engineering  Change  Proposals  (ECPs),  Specifications  Change  Notices  (SCNs),  Waivers 
and  Deviations.  Maintain  documentation  technical  content  accuracy. 

CONFIGURATION  SUPPORT:  Perform  necessary  review  to  verify  that  production  hardware  matches 
the  design  equations.  Resolve  incompatabilities  between  hardware  and  design.  Provide  fabrication 
proceedures  to  contractors  and  assist  in  the  resolution  of  production  problems.  Support  Level-of- 
Effort  contracts  and  propose  design  changes  to  improve  prcducibility.  Evaluate  special  designs  and 
hardware  modifications  and  estimate  the  cost  impact  of  design  changes  including  implementation 
and  production  costs. 

PRODUCT  ASSURANCE  SUPPORT:  Participate  in  pre-  and  post-award  surveys,  quality  audits, 
contractor  /contracting  officer  technical  meetings  and  facilities  conferences.  Maintain  facilities 
and  perform  quality  assurance,  acceptance  qualification  and  failure  analysis  testing.  Review  and 
evaluate  contractors  production,  test,  handling  and  assembly  procedures  to  improve  producibility. 
Perform  first  article  inspections  and  tear  downs  as  required.  Conduct  failure  mode  studies  to  improve 
reliability.  Perform  design  and  certification  of  special  test  equipment  for  use  during  the  production 
contract. 


REPORTING: 

Monthly  reports  in  the  format  of  enclosure  (1)  will  be  submitted  to  the  Program  Office  no  later 
than  the  10th  of  the  following  month. 


♦funding'  “ 

Applicable  Job  Orders: 

ACF  — Safety  and  Arming  Device  ACI  — Wings  and  Fins 
ACG  — Warhead 
ACH  — Rocket  Motor 
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SAMPLE  MONTHLY  REPORT 


FROM  (Reporting  Code) 

TO  Sidewinder  Program  Office,  Code  36202 

SUBJ  (month)  Report  of  Sidewinder  Tasks 

1.  Customer  Order  Title  and  No.  (Sidewinder  AIM-9L  Production,  1367205) 

a.  Job  Order  No.  (ANA) 

(1)  ACCOMPLISHMENTS 
Summary  of: 

1)  tests  completed 

2)  publications  completed 

3)  reports  completed 

4)  drawings  completed 

5)  significant  correspondence 

6)  significant  events/break-thrus 

(2)  PROBLEMS 

Summary  of  problems  encountered. 

(3)  TRAVEL 

Summary  of  travel  including  purpose  and  results. 

(4)  VIP  Visits 

Summary  of  visitors  including  purpose  and  results  of  visits. 

b.  Job  Order  No.  (ANB) 

(Same  format  as  l.a.  above.) 

2.  Customer  Order  Title  and  No.  (Sidewinder  AIM-9H  Production,  1367705 
(Same  format  as  1.  above.) 


(Reporting  Official) 


Enclosure  (1) 
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